Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Why doesn't "switch" statement have "break" as default?

Reply
Thread Tools

Why doesn't "switch" statement have "break" as default?

 
 
Chris Uppal
Guest
Posts: n/a
 
      05-26-2005
Mike Schilling wrote:

> > Would you scream blue murder is Sun eventually removed some API's that
> > have been deprecated for a long time?

>
> If it broke a working application for which I didn't have the source code?
> Yes.


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.

-- chris


 
Reply With Quote
 
 
 
 
John McGrath
Guest
Posts: n/a
 
      05-26-2005
On 4/26/2005 at 6:36:45 PM, Boudewijn Dijkstra wrote:

> This is why:
>
> switch (type)
> {
> case COMMAND_RC5:
> case COMMAND_RC5_STRING:
> case COMMAND_RC6_MODE_0:
> buf = new byte[4];
> buf[0] = info;
> contentIndex = 1;
> break;
> case COMMAND_RC5_EXTENDED:
> case COMMAND_CDI:
> case COMMAND_RC6_MODE_2A:
> buf = new byte[5];
> buf[0] = info;
> contentIndex = 1;
> break;

:
:
> }


If that were it, then a much better approach would have been to use a
syntax similar to the Pascal case statement. In other words, allow
multiple values in a switch block, and have an automatic break at the
end of the block.

switch (type)
{
case COMMAND_RC5, COMMAND_RC5_STRING, COMMAND_RC6_MODE_0:
buf = new byte[4];
buf[0] = info;
contentIndex = 1;
case COMMAND_RC5_EXTENDED, COMMAND_CDI, COMMAND_RC6_MODE_2A:
buf = new byte[5];
buf[0] = info;
contentIndex = 1;
:
:
}

--
Regards,

John McGrath
 
Reply With Quote
 
 
 
 
Lucy
Guest
Posts: n/a
 
      05-26-2005

"Mike Schilling" <(E-Mail Removed)> wrote in message
news:qInle.1645$(E-Mail Removed) ...
>
> "Dale King" <(E-Mail Removed)> wrote in message
> news:YDble.6982$g66.2345@attbi_s71...
>
> > I would certainly agree if they made the change instantaneously, but as

I
> > said it is a multiple step process to get there. Essentially, the plan

is
> > to deprecate language syntax just like API's can be deprecated. Would

you
> > scream blue murder is Sun eventually removed some API's that have been
> > deprecated for a long time?

>
> If it broke a working application for which I didn't have the source code?
> Yes.


Is it because you (OP) are lazy? There are tools that you can run
that will tell you of potential trouble due to this. Takes only
a few seconds to run.


 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      05-26-2005

"Chris Uppal" <(E-Mail Removed)-THIS.org> wrote in message
news:4296386e$0$38046$(E-Mail Removed).. .
> Mike Schilling wrote:
>
>> > Would you scream blue murder is Sun eventually removed some API's that
>> > have been deprecated for a long time?

>>
>> If it broke a working application for which I didn't have the source
>> code?
>> Yes.

>
> You may have been talking about APIs in general, rather than the
> switch/case
> syntax in particular.


Yes. Sorry if that wasn't clear.

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


Agreed.


 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      05-27-2005
Lucy coughed up:
> "Mike Schilling" <(E-Mail Removed)> wrote in message
> news:qInle.1645$(E-Mail Removed) ...
>>
>> "Dale King" <(E-Mail Removed)> wrote in message
>> news:YDble.6982$g66.2345@attbi_s71...
>>
>>> I would certainly agree if they made the change instantaneously,
>>> but as I said it is a multiple step process to get there.
>>> Essentially, the plan is to deprecate language syntax just like
>>> API's can be deprecated. Would you scream blue murder is Sun
>>> eventually removed some API's that have been deprecated for a long
>>> time?

>>
>> If it broke a working application for which I didn't have the source
>> code? Yes.

>
> Is it because you (OP) are lazy? There are tools that you can run
> that will tell you of potential trouble due to this. Takes only
> a few seconds to run.


To whom are you referring? Who is the original poster that you are talking
about? Certainly not /the/ OP for the thread, because you only quoted Mike
Schilling and Dale King....

--
"Well, ain't this place a geographical oddity!
Two weeks from everywhere!"


 
Reply With Quote
 
Dale King
Guest
Posts: n/a
 
      05-31-2005
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, 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

I could understand having personal issue with the first, but if you have
trouble with the second I would like to understand why. As I point out
in the comments section of the RFE they can actually have some
performance beneifts.
--
Dale King
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      06-06-2005
[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





 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
How do I do a conditional statement in a constant statement? tkvhdl@gmail.com VHDL 3 12-16-2005 06:13 PM
unless statement... why oh why? Zach Dennis Ruby 6 08-18-2005 11:56 PM



Advertisments