Submission: switch (...) instanceof feature (original) (raw)

Jeroen van Maanen jeroen at lexau.org
Sun Mar 29 13:43:02 PDT 2009

Artur Biesiadowski wrote:

1) Why case void: instead of case null: ?

Yes, I agree that it is potentially confusing. At the other hand, null is an instance not a type. It would also be possible to add a type or even a keyword to describe the type of null, but that would increase the impact of the change and it would mean another type with no instances. I thought that void would pretty much fit the descrition of what I would like: a keyword that indicates a type that would not have any actual instances. I suppose that if we are stretching the exact meaning of the terms anyway, then 'case null:' would probably just be as well and easier to remember.

2) What is a expected behavior in case of multiple matches ? For example

I propose to do strict top-down first-match-only evaluation, because if the given variable matches many of the labels and the types of the labes belong to a complicated hierarchy of interfaces, then reordering the cases according to inheritance could lead to unpredictable results. I don't think that executing all matching blocks would be a good idea, because I think that many code readers would not expect this from a switch statement. Although it would be possible to allow a fallthrough from a specific type to a super type, I am afraid that allowing such highly constrained constructions would lead to code that is hard to read and easy to misunderstand.

switch(collection) instanceof {

case RandomAccess: ... case List: ... case Collection: ...

} Do I need to put switch cases in correct order because of top-to-down evaluation or most specific one will be used? Or maybe all matching ones ? 3) I think you have forgotten to put 'break' in your examples, unless you plan to disallow fall-through.

Ah, I should have made that explicit. No breaks necessary and no lists of labels before a statement block. I could not think of a way to get the casts right in a fallthrough situation. Maybe it would be less confusing to make break a compulsory statement at the end of each statement block. That is:

TypeSwitchBlockStatementGroup: TypeSwitchLabel BlockStatements break ;

What do you think?

Regards, Artur Biesiadowski

I just thought about another situation that needs to be clarified:

  1. How does the switch instanceof statement handle generics?

I would like to see

switch (model) instanceof { FreeMarkerModel: template.process(..., model); Map: template.process(..., toFMM(model)) }

translated as

if (model instanceof FreeMarkerModel) { FreeMarkerModel model$1 = (FreeMarkerModel) model; template.process(..., model$1); } else if (model instanceof Map) { Map model$2 = (Map) model; template.process(..., toFMM(model$2)); }

So each type parameter that we cannot guess would be specified as ?.

The following would be illegal, because the specification allows no type parameters after the type name in a label.

switch (model) instanceof { ... Map<String,Object>: ... }

This is fine, because I can't think of a way where the desugared code would be free of "unchecked" warnings.

Regards, Jeroen

More information about the coin-dev mailing list