+= and =

[Arne Vajhøj]

Generally in Java, integral types don't throw overflows, and there's a
lot of code (e.g., 'hashCode()') that depend on that.

It can not be changed.

I like the check. But if that check is the requirement then maybe Java
is not the best language.

I don't believe in the super language that has all possible features and
are best to everything.

Arne

 

[Wojtek]

Arne Vajhøj wrote :

Yes.

It allows programmers to save a bit of typing by reusing code
via fall through at the expensive of producing no compile time
error and weird runtime errors if the programmer forget a break.

That is a bad deal.

As is every logic error.

It is very unlikely that it will ever be changed. It would
break existing code.

switch/case fall through was part of the K&R C book almost 30 years
ago.

My trivial example aside, there are many places where it is better to
use it. I once used it to write a method which returned the julian
date. Something along the lines of (I might have this wrong as I am
doing this from memory):

switch ( monthIn )
{
int days = 0;

case 12:
days += 31;
case 11:
days += 30;
....
case 2;
days += 28 + (isLeapYear(yearIn)?1:0);
case 1:
days += dayIn;
}

But it should have been designed different 15 years ago to
match the true Java spirit.

You must explain this statement. switch/case fall through vs the true
Java spirit.

 

[Andreas Leitgeb]

The feature of saving lines of code at the expense of making
programming errors runtime errors instead of compile tile errors
is neither in the Java spirit or an advantage in my opinion.

In this particular context (namely if it were 15 years earlier),
usage of "continue;" for cross-"case" proceeding (with automatic
breaking on lack of that statement) might have been an alternative...

.... but a rather tedious one in those cases where several switch-
values are supposed to run exactly the same code, unless some special
case was made for immediately subsequent case labels.

Btw., As a contrast, Tcl has separate switch-arms with only very
specific fall-through: Any switch-arm is either a block of code
without fall-through or a special marker that means "use next
non-marker block of code found".
There is no direct way to fall through from one real block to any
other. Though, of course, one can place the switch into a loop
and reiterate it with the switch variable appropriately modified.

 

[RedGrittyBrick]

In this particular context (namely if it were 15 years earlier),
usage of "continue;" for cross-"case" proceeding (with automatic
breaking on lack of that statement) might have been an alternative...

That would suit me fine.

... but a rather tedious one in those cases where several switch-
values are supposed to run exactly the same code, unless some special
case was made for immediately subsequent case labels.

switch (month) {
case 1,3,7,8,10,12: days=31;
case 2: days=leap(year)?28:29;
default: days=30;
}

Just my ¤0.00000000000000000000000000000000000000000000002 worth!

 

[Andreas Leitgeb]

That is a third solution.
But I don't think that would be popular either.

A fourth solution would overflow just like (byte)(a+b), but
would give the programmer access to typical microprocessor's
"carry"-flag. i.e. perform addition as an (n bits)->(n+1 bits)
operation (for n in 8,16,32,64). Theoretically, throwing an
exception could cover that case, if it kept the truncated
sum in a field of the exception - it would just be very weary
to use.

 

[Andreas Leitgeb]

That would suit me fine.
switch (month) {
case 1,3,7,8,10,12: days=31;
case 2: days=leap(year)?28:29;
default: days=30;
}

Yes, I agree. This way, it would have been practical.
(just judging the syntax, not the snippet itself)

Alas, too late now.

Check out Mark Space's posting w.r.t. Java 7. Perhaps one
could still suggest multivalued case labels (additionally to
current multiple subsequent each singlevalued "case"s).
Not quite the primary topic of this subthread, but anyway.

 

[Andreas Leitgeb]

Check out Mark Space's posting w.r.t. Java 7. Perhaps one
could still suggest multivalued case labels (additionally to
current multiple subsequent each singlevalued "case"s).
Not quite the primary topic of this subthread, but anyway.

That thread's topic is "Small language changes".

 

[blue indigo]

Something along the lines of (I might have this wrong as I am
doing this from memory):

switch ( monthIn )
{
int days = 0;

case 12:
days += 31;
case 11:
days += 30;
...
case 2;
days += 28 + (isLeapYear(yearIn)?1:0);
case 1:
days += dayIn;
}

Yep. That is, you have it wrong. The lack of a days+=31 for January is a
big fat clue. Should probably be:

int days = 0;
switch (monthIn) {
case 12:
days += 30;
case 11:
days += 31;
case 10:
days += 30;
case 9:
days += 31;
case 8:
days += 31;
case 7:
days += 30;
case 6:
days += 31;
case 5:
days += 30;
case 4:
days += 31;
case 3:
days += 28 + (isLeapYear(yearIn)?1:0);
case 2:
days += 31;
case 1:
days += dayIn;
}

As a check, today is March 3, so daysIn would be 3 and monthIn would be 3.
So we arrive at case 3, add the 28 days in February (since yearIn == 2009
is not a leap year), fall through, add the 31 days in January, fall
through again, and add the 3 (so far) days in March to get 62; this is the
62nd day of 2009. (When it's not the 5906th day of 1993, that is.)

(I also fixed a case label ending with ; instead of : and an int being
declared inside the switch body, but outside of any case.)

 

[RedGrittyBrick]

Yes, I agree. This way, it would have been practical.
(just judging the syntax, not the snippet itself)

Alas, too late now.

Unless someone allows a switchwithimplicitbreak keyword?

I'm sure someone can come up with a better shorter keyword
breakingswitch?
switchnbreak?
switchbreak?
choose?

Check out Mark Space's posting w.r.t. Java 7. Perhaps one
could still suggest multivalued case labels (additionally to
current multiple subsequent each singlevalued "case"s).
Not quite the primary topic of this subthread, but anyway.

I did, my attempt to post a comment didn't work as I don't have an ID on
sun's blogging area and the proposed discussion forum thingy isn't there
(yet?)

 

[Wojtek]

blue indigo wrote :

 

[Arne Vajhøj]

In this particular context (namely if it were 15 years earlier),
usage of "continue;" for cross-"case" proceeding (with automatic
breaking on lack of that statement) might have been an alternative...

That would have been a fine solution.

Why were you not in Gosling's office 15 years ago ?



Arne

 

[Arne Vajhøj]

A fourth solution would overflow just like (byte)(a+b), but
would give the programmer access to typical microprocessor's
"carry"-flag. i.e. perform addition as an (n bits)->(n+1 bits)
operation (for n in 8,16,32,64). Theoretically, throwing an
exception could cover that case, if it kept the truncated
sum in a field of the exception - it would just be very weary
to use.

Too assemblerish in my opinion.

Arne

 

[Arne Vajhøj]

Arne Vajhøj wrote :

As is every logic error.

It was not the programming error that was a bad deal, but the
risk of getting such errors in exchange for saving some lines
of code.

switch/case fall through was part of the K&R C book almost 30 years ago.

I know.

But if Java has dropped it from day 1 then it would not have
broken any code (C code does not compile in Java).

Today it is too late. There must be some code somewhere out there
that relies on the feature.

You must explain this statement. switch/case fall through vs the true
Java spirit.

See above about the "bad deal".

Arne

 

[Arne Vajhøj]

Unless someone allows a switchwithimplicitbreak keyword?

I'm sure someone can come up with a better shorter keyword
breakingswitch?
switchnbreak?
switchbreak?
choose?

(I put on my asbestos suit)

Or select ?

Arne

 

[Arne Vajhøj]

Unless someone allows a switchwithimplicitbreak keyword?

I'm sure someone can come up with a better shorter keyword
breakingswitch?
switchnbreak?
switchbreak?
choose?

I am not convinced that the benefits of the change in this part of
Java's lifecycle will be worth the confusion of having two
switch statements.

Arne

 

[Wojtek]

Arne Vajhøj wrote :

But if Java has dropped it from day 1 then it would not have
broken any code (C code does not compile in Java).

Well, Visual Basic does not have case fall through, and it does allow
multiple values within the case syntax. It also allows adhoc tests in
the case syntax so you are not limited to numerical values.

That having been said, there are times when I needed to write more code
to get around this "feature".

Today it is too late. There must be some code somewhere out there
that relies on the feature.

"must be"?

Programmers tend to use the symantics of a language. But if you have a
philosophical objection, well that is allowed too.

For instance I use scriptlets (gasp!) in JSP pages, rather than trying
to shoehorn everything into a tag library.

IMHO tag libraries make it easier for non-programmers yet hide the
details, but scriptlets are deemed to be "too hard", yet show exactly
what is happening.

 

[Arne Vajhøj]

Arne Vajhøj wrote :

"must be"?

Is is almost as Newtons laws in physics - if the language syntax
allows something then somebody will use that feature - no matter
how ugly it is.

Programmers tend to use the symantics of a language. But if you have a
philosophical objection, well that is allowed too.

For instance I use scriptlets (gasp!) in JSP pages, rather than trying
to shoehorn everything into a tag library.

IMHO tag libraries make it easier for non-programmers yet hide the
details, but scriptlets are deemed to be "too hard", yet show exactly
what is happening.

Scriptlets mix code and markup.

Which I think is bad.

But I would never suggest removing the scriptlet capability from
JSP, because I know the feature is used out there.

Arne

 

[Wojtek]

Arne Vajhøj wrote :

Is is almost as Newtons laws in physics - if the language syntax
allows something then somebody will use that feature - no matter
how ugly it is.


Scriptlets mix code and markup.

Which I think is bad.

But I would never suggest removing the scriptlet capability from
JSP, because I know the feature is used out there.

Depends on the code. I use flags in my data object to indicate which
buttons, input fields and so on should be seen by the end user. The
logic which sets the flags lives in the business logic object.

So all the code in a servlet is towards presentation, not to make
descisions.

Mix in some CSS, DHTML, and Javascript and there you go.

 

[Lew]

Depends on the code. I use flags in my data object to indicate which
buttons, input fields and so on should be seen by the end user. The
logic which sets the flags lives in the business logic object.

On the face of it, this description indicates a suboptimal architecture. I
suspect the actual code is cleaner than you make it sound.

Data objects have no business deciding what should be visible.

So all the code in a servlet is towards presentation, not to make
descisions.

This contradiction of the earlier sentence is my clue that your architecture
is cleaner than you make it sound.

Mix in some CSS, DHTML, and Javascript and there you go.

Hopefully not in the data object.

 

[Wojtek]

Lew wrote :

This contradiction of the earlier sentence is my clue that your architecture
is cleaner than you make it sound.

This is why we have white boards...