Strings in Switch

[Lawrence Kesteloot]

Now that we plan to have closures, do we still need strings-in-switch?
Won't a string-to-function map be about as fast (though maybe less
convenient)? I don't know what the use cases are for
strings-in-switch, but the feature already felt a bit low-benefit to
me, and seems even more so now with closures.

Lawrence


On Sun, Dec 6, 2009 at 10:07 PM, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
> Paul Benedict wrote:
>> Joe,
>>
>> I reviewed the check-in and read a presentation about the
>> implementation. I get that it translates into two switch statements,
>> but I think there are cases where the duality can be eliminated. If
>> the first switch statement produces no hash collisions, I don't think
>> the second switch statement is necessary. Thoughts?
>>
>>
>
> There are many possible desugarings of strings in switch into one or
> more switch statements and other existing code structures, some of which
> are alluded to the comments of the current strings in switch implementation.
>
> If there is no "bad" control flow in the original strings in switch (no
> fall throughs, etc.) and no collisions with the chosen hash function,
> then yes the the code
>  case "foo":
> can be replaced with
>  case "foo".hashCode():
>      if ("foo".equals(...")) {...}
> if care is taken to implement the semantics of any default alternative
> that is present.
>
> However, for the initial strings in switch implementation in javac, we
> choose to pursue a single general-purpose strings in switch translation
> that should always provide at least reasonable performance since it
> results in less compiler code to test for what is currently a low
> duty-cycle code structure.
>
> If special cases of strings in switch turn out to have high duty-cycles,
> that would justify additional engineering to support different
> implementations tailored to different code inputs.
>
> -Joe
>
>
>