Strings in Switch

[Reinier Zwitserloot]

inline.

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

> It's interesting that one of the arguments for closures is that it
> makes language feature less necessary, but now suggesting that this
> feature might be less necessary is "going closure crazy".
>
>
Please don't respond to emails until you read all of them. I explained why
your idea is going closure crazy in the next paragraph.


> A triviality?
>

You misunderstand my words. The fact that switch DOES work on ints, but does
NOT work on Strings, _THAT_ is trivia. You have to know. It's not obvious.
It seems like an arbitrary restriction. Doing away with this restriction is
good. In fact, for the next coin, I wouldn't be opposed to enabling longs in
switch as well, for the same reason. Consistency amongst the concept of
compile time literals. All primitives, and Strings, can come in 'literal'
form. This is relevant in a number of places, including compile-time
inlining of constants. However, for switch, there are 3 exceptions:
booleans, longs, and Strings. Booleans are irrelevant for obvious reasons.
Strings are now getting added. Which leaves just the longs.

Also, "people have to learn it"? No. There's not a soul on this earth who
knows what java switch statements are that is going to be confused by
strings in switch. People WOULD have to learn to use a library and/or
pattern based around a Map<String, #(String)void>, though.

That's 100% irrelevant. You don't add a feature to a language just
> because the work has been done.


There's a limited budget to spend on improving java. We've already spent a
lot of it here. It got through coin, a lot of peer review, and it hasn't run
into serious opposition until you brought it up. Of course it's relevant.


> > 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.
>
> Good point.
>
>
Yes, it is.