Re: Why doesn't "switch" statement have "break" as default?
- From: "Chris Uppal" <chris.uppal@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 6 Jun 2005 09:28:45 +0100
[Sorry about the late reply]
Dale King wrote:
> Chris Uppal wrote:
> >
> > You may have been talking about APIs in general, rather than the
> > switch/case syntax in particular. I don't even slightly support the
> > idea of "fixing" Java's switch/case semantics (one ot the crowning
> > glories of C, IMO) but I see no reason why introducing Dale's
> > abominable (I /M/ O) modifications should have any effect at all on the
> > generated bytecode, so binary compatibility should not be an issue.
>
> I take no offense at your opinon of my suggestions,
Good. It wasn't my intent to give offense, I'm glad it didn't.
> but I'm curious what
> you find so abominable about the suggestions. Perhaps I'm not sure
> exactly which ones you find abominable. There were basically two types
> of suggestions:
>
> - handling fall-through explicit vs. implicit
> - adding lists, ranges, etc. to cases
More the first than the second, but neither really captures what I don't like.
Here's my shot at explaining.
The 'C' switch statement is in no way syntactic sugar for a cascade of if-else
statements. If it's syntactic sugar at all, then it's sugar for an assigned
GOTO. The semantics of switch are a surfacing of a vitally (IMO) important
underlying implementation technique (jump table), and as such it seems to me
not only suitable, but even inevitable, that the 'case' values act as labels
(in the GOTO sense). I wouldn't want to dilute that.
BTW, I do realise that the compiler and/or JIT is allowed to implement any
given switch as an if-then cascade or a hash table lookup (or similar) if it
deems that to be better -- I'm talking about the semantics that the programmer
sees, not the /actual/ implementation technique (unless the compiler goes
overboard in not honouring my wishes as expressed in the code).
As to the proposal to add lists and ranges, a couple of comments, not entirely
tied to the above:
I don't see the point of having comma-separated lists of values. That seems to
me to be change for change's sake (with concomitant impact on all tools that
make use of Java in source form -- such as Eclipse). It seems to be exchanging
one form of readability for another. If both forms are allowed, then the
visual complexity of the source increases (since there are two different ways
of expressing /exactly/ the same thing). If only one or the other were allowed
then I'd marginally prefer the one we already have, since it works well for
long identifiers.
I'd -- by a small margin -- support ranges. That, too, is adding complexity,
but I'm prepared to believe that it would be able to pay its way. I'm less
sure that it would /also/ be able to justify the costs of a change to the
language -- that's to say, if ranges had been there from the beginning, then I
doubt whether I'd see then as a mistake, but I'm not eager to see /more/
language changes at this stage. BTW, one specific technical problem with
adding ranges is that the JVM puts hard limits on how many switch values are
allowed, and those limits would translate into apparently arbitrary (and very
easily exceeded) limits on the Java source code.
I'd still have reservations, too, in that I think that ranges -- unless very
carefully presented as /only/ syntactic sugar -- would dilute the jump-table
aspect which I want to preserve. To see that, consider what happens when
ranges overlap. Should that be simply forbidden ? I would say yes, but
another reader might want to allow overlaps, but make the first match be the
one that was selected. To me, that suggestion can only arise if someone has
already lost the sense of a switch as being a jump table.
If what you want is really a multi-way 'if', then I'd rather see it presented
as such -- ie. as a new syntactic structure designed in such a way that its
semantics were those of an if-then cascade but which the compiler understood
well enough (in well-defined ways) to be able to apply optimisations like
hashing where appropriate. Of course that would be adding another linguistic
construct, which I've already said that I don't want to see, but -- on
balance -- I think I'd prefer that to hacking around with the 'C' family's
crowning glory ;-)
-- chris
.
- Prev by Date: Re: Text color in Windows console
- Next by Date: Re: URLConnection "memory leak"
- Previous by thread: get svn version
- Next by thread: exchange of unsigned values in network protocols
- Index(es):
Relevant Pages
|
