Strings in Switch

[Reinier Zwitserloot]

Let's no go closure crazy. The fact that switch does NOT support strings
today is a silly triviality that catches out many beginning java
programmers.

A lot of the hard work on this proposal has already been done, so abandoning
it now does not seem like a good idea.

Also, Mark Reinhold's plan for closures does not include transparency, which
would make a closure-based function map much inferior to strings in switch
which is of course transparent.

--Reinier Zwitserloot



On Mon, Dec 7, 2009 at 7:14 AM, Lawrence Kesteloot <lk at teamten.com> wrote:

> 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
> >
> >
> >
>
>