JCK feedback on "Strings in Switch" proposal
Ulf.Zibis at gmx.de
Mon May 25 07:14:38 PDT 2009
>> I think it would be better to define "expression == constant" for
>> several reasons.
>> (1) "switch..case" syntax historically is expected to be very fast.
>> See discussions on:
>> (2) Comparison for identity would better match to legacy semantics of
>> "switch..case" statement.
> No, it would not. Comparing strings for "==" equality is a common
> programming error so the semantics of strings in switch should be
> defined in terms of .equals equality.
I think, I got your opinion.
Variables are equal, if the values of their chunk of bits are identical
(not generally, but in case of primitives and String objects).
Variables are identical, if the memory location of their chunk of bits
is the same. So primitive variables are never identical, as their chunk
of bits are stored in different memory locations, and pedantically
argued, "i == j" (for primitives) is always false, they should be
compared by "i.equals(j)". Theoretically we could define "==" as
comparison method for the switch..case construct, and accept the upper
imprecision as legal for primitives. If the programmer wants comparison
by equals(), he should explicitly write the syntax for it, e.g. in the
way, I have proposed in my "switch for objects and expressions"-proposal.
Having this, comparing by "==" can be seen as a programmatically
shortcut for "equals()" in case of interned String objects (Literals are
automatically interned by definition).
There are 3 interesting, widely used types of comparison of Strings:
- s1 == s1
The first 2 are covered by the given "Strings in Switch" proposal.
IMHO we should not abandon the attempt to provide a smart syntax for the
3rd type of comparison in case of Strings, and even similar for general
if..else constructs seem not to be smart.
More information about the coin-dev