Submission: switch (...) instanceof feature

[Ulf Zibis]

Am 22.04.2009 18:06, Gabriel Belingueres schrieb:
>
> Do you mean memory footprint? You may implement those Strategies as
> Singletons if you know they do not store any state, or even as a
> Flyweights if the different instances are limited. I would keep it as
> simple as possible.
>   

1st I mean jar-footprint, but 2nd I also mean memory footprint and not 
to forget class loading, object initialization and indirection time.

>
> IMO, readability is not important very important if the application
> life cycle will be short. I would apply the KISS principle again.
>   

Do you think, sun.nio.cs.FastCharsetProvider is kind of short life cycle 
? ;-)

>
> If the lookup method is the only place you do the instanceof test,
> then it seems reasonable to keep it that way, instead of creating all
> that strategy pattern code.
> However, I can not see how changing the instanceof by a switch
> statement would improve the code,

Think about READABILITY, READABILITY and READABILITY.

if..else is good for 2-way fork, but IMHO switch..case is better for 
n-way fork.
See: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001182.html

In case of instanceof additionally casting could be omitted.

>  UNLESS the switch statement adds
> some value, for example that it would perform far better than an
> if-elseif-else chain AND do some checks, like throwing a compiler
> error when I write something like this:
>   

+1

> class A {}
> class B extends A {}
>
> ...
> switch(o) instanceof {
> case A:
>   // do something with this A instance
>   break;
> case B:
>   // never enter this branch if it's a B because it is always catched by the
>   // previous case
>   break;
> ...
> }
>
>
>