why is Java the way it is?

[Roedy Green]

Why is this illegal?

while ( int place = s.indexOf( x ) >= 0 )
{
...
}
you have to write it:

int place;
while ( place = s.indexOf( x ) >= 0 )
{
...
}


If for can do it, why not while?

 

[EJP]

If for can do it, why not while?

Good question. The content of an 'if' statement is essentially either
(<statement>; <expression>; <statement>)
or
(<declaration>; <expression>; <statement>).

The content of a while-condition is just <expression>.

Allowing a <declaration> in a while-condition would be +less+
symmetrical with 'for' than <expression> is: it would imply
re-initialization of the item every time around the loop, which is
asymmetric with 'for', where it only happens once.

 

[Roedy Green]

Allowing a <declaration> in a while-condition would be +less+
symmetrical with 'for' than <expression> is: it would imply
re-initialization of the item every time around the loop, which is
asymmetric with 'for', where it only happens once.

That makes sense logically. Pragmatically it forces you to expose
variables to wider scope than they should have.

 

[Dirk Michaelsen]

Why is this illegal?

I don't know the reason but...

int place;
while ( place = s.indexOf( x ) >= 0 )
{
..
}

....this code does not compile. you have to write

while ( (place = s.indexOf( x )) >= 0 ) {

If for can do it, why not while?

why then you don't use for?

for (int place; (place = s.indexOf(x)) >= 0 {

and if you prefer using while and want to redefine variable place
later again you can put the code block into braces:

{
int place;
while ( place = s.indexOf( x ) >= 0 )
{
..
}
}

int place = 42;

Dirk

 

[Ian Semmel]

Why is this illegal?

while ( int place = s.indexOf( x ) >= 0 )
{
..
}
you have to write it:

int place;
while ( place = s.indexOf( x ) >= 0 )
{
..
}


If for can do it, why not while?

Well, none of these statements compile on my java but

Probably because they are different statements

while ( booleanExpression) statement;

for (ForInit;Expression;ForUpdate) statement
where
ForInit is StatementExpressionList OR LocalVariableDefinition

You can't define a variable in a boolean expression

This is ok
int place;
boolean b = ( ( place = s.indexOf ( 'a' ) ) >= 0 );
while ( b ) {}

This is not
boolean b = ( ( int place = s.indexOf ( 'a' ) ) >= 0 );

 

[Motosauro]

Ian Semmel ha scritto:

Well, none of these statements compile on my java but

Probably because they are different statements

while ( booleanExpression) statement;

for (ForInit;Expression;ForUpdate) statement
where
ForInit is StatementExpressionList OR LocalVariableDefinition

You can't define a variable in a boolean expression

This is ok
int place;
boolean b = ( ( place = s.indexOf ( 'a' ) ) >= 0 );
while ( b ) {}

This is not
boolean b = ( ( int place = s.indexOf ( 'a' ) ) >= 0 );

Ok, but in the first case b gets evaluated only the first time:
if it evaluates to true it would be like writing
while(true){}

You should put the evaluation inside the while loop, or change it into a
do-while loop, in order to assign the 'place' variable before evaluating it

What I would do though would be :
int place = 0;
while(s.indexOf(x)>=0){
place = s.indexOf(x);
/* do something with place*/
x++; /* or whatever counter would be appropriate */
}

 

[mv1945]

Roedy Green escribió:

Why is this illegal?

while ( int place = s.indexOf( x ) >= 0 )
{
..
}
you have to write it:

First al all: place must be boolean

int place;
while ( place = s.indexOf( x ) >= 0 )
{
..
}

There are no sense to redefine place in each iteraction

If for can do it, why not while?

In a for sentence eg:
for ( int i=0; i<10;i++)
int i=0 initilize the variable but it the same al time.

Regards

 

[Tom Anderson]

while ( booleanExpression) statement;

for (ForInit;Expression;ForUpdate) statement
where
ForInit is StatementExpressionList OR LocalVariableDefinition

You can't define a variable in a boolean expression

Or indeed, any expression. This:

int x = (int y = 1) + 1;

Isn't legal. This:

int y ;
int x = (y = 1) + 1;

Is. That's the crux of it.

The for loop is an aberration, in that it has a very complicated
parenthesised bit.

I do agree that this is sort of annoying, though. Being able to declare a
variable in the loop condition of a while would be tidier than having to
declare it before the loop.

tom

--
It not infrequently happens that something about the earth, about the sky,
about other elements of this world, about the motion and rotation or even
the magnitude and distances of the stars, about definite eclipses of the
sun and moon, about the passage of years and seasons, about the nature
of animals, of fruits, of stones, and of other such things, may be known
with the greatest certainty by reasoning or by experience. -- St Augustine

 

[Daniele Futtorovic]

The for loop is an aberration, in that it has a very complicated
parenthesised bit.

I do agree that this is sort of annoying, though. Being able to declare
a variable in the loop condition of a while would be tidier than having
to declare it before the loop.

Given that you can use a 'for' over a 'while' any time and, AFAIAA,
without any penalties, I don't find that annoying at all. I prefer the
'for' anyway.

 

[Andreas Leitgeb]

Roedy Green escribió:
It reminds me of my casual wish to just save away some
interims-result of a formula, and have the compiler
just "dup" it on the stack for immediately subsequent
use, rather than "store" it into a local variable and
(immediately subsequently) load it back from there.

But usually, I then remember the dogma about "the jit
does all the kinky magic for me - it knows *much* better
than me" and I then just save the value into a local
variable.

And then I'm wondering, why (or whether)
String all=""; for(/*some long loop*/) all += next_part;
is still my responsibility to rewrite for using explicit
StringBuilder.

 

[Patricia Shanahan]

Why is this illegal?

while ( int place = s.indexOf( x ) >= 0 )
{
..
}
you have to write it:

int place;
while ( place = s.indexOf( x ) >= 0 )
{
..
}


If for can do it, why not while?

The for loop has an initialization clause whose result, if any, is not
used, so a declaration fits in nicely there.

Patricia

 

[Daniel Pitts]

That makes sense logically. Pragmatically it forces you to expose
variables to wider scope than they should have.

No, but you can accidentally expose them to a wider scope if you don't
think about it.
void myMethod() {
doSomething();
{
int foo = 10;
while (foo < 100) {
foo = nextFoo(foo);
}
// foo is not in scope here.
doSomethingElse();
}

 

[Tom Anderson]

Given that you can use a 'for' over a 'while' any time and, AFAIAA,
without any penalties,

Without penalties? What are those two semicolons, then?

I don't find that annoying at all. I prefer the 'for' anyway.

Fair enough. Personally, i find the for loop syntax really clumsy.

This:

int place ;
while ((place = s.indexOf(x)) >= 0 ) ...

Can be written:

for (int place; (place = s.indexOf(x)) >= 0 ...

But that looks hell of ugly to me - it's got a repetition of the variable
name and two completely pointless semicolons.

This:

while ((int place = s.indexOf(x)) >= 0) ...

Would be much nicer. Although then you'd have to allow declarations inside
expressions, and the world would rapidly go mad. This:

this.foo = someBoolean ? (int bar = 23) : ((String bar = "baz").hashCode()) ;

Would be fun. I guess the rule would be that any statement involving a
declaration inside an expression gets rewritten as a block comprising the
declaration followed by the expression with the declaration changed to an
assignment. So Roedy's example would become:

{
int place ;
while ((place = s.indexOf(x)) >= 0 ) ...
}

Exactly as desired, and the troublemaking example would become:

{
int bar ;
String bar ;
this.foo = someBoolean ? (bar = 23) : ((bar = "baz").hashCode()) ;
}

Which would then fail to compile, because of the conflicting decarations
of bar.

You'd have to be a bit clearer about scope, though. Clearly, this:

int foo = (int bar = 23) + 1 ;
baz(foo) ;

Couldn't be rewritten to this:

{
int bar ;
int foo = (bar = 23) + 1 ;
}
baz(foo) ;

Because it screws up the scope of foo. It'd have to be:

int foo ;
{
int bar ;
foo = (bar = 23) + 1 ;
}
baz(foo) ;

There are doubtless other traps.

tom

 

[Roland de Ruiter]

[...]
for (int place; (place = s.indexOf(x) >= 0; )

Oh, drat. Precedence and syntax bugs seem rampant
throughout this whole thread. What I *meant* was

for (int place; (place = s.indexOf(x)) >= 0; )

If you really hate parenthesis (and don't mind duplicating expressions),
why not
for (int place = s.indexOf(x); place >= 0; place = s.indexOf(x))

 

[Claudio Nieder]

Hi,

And then I'm wondering, why (or whether)
String all=""; for(/*some long loop*/) all += next_part;
is still my responsibility to rewrite for using explicit StringBuilder.

Unless that long loop is the most time-critical or memory consuming part
in my application, I wouldn't care whether to use StringBuilder or not.

And if I think it could be, I would first benchmark it and see whether
the StringBuilder solution really saves me some time or space or if the
JIT is able to optimize it well enough.

claudio (also guilty of sometimes optimizing, when not in need to)

 

[Andreas Leitgeb]

Unless that long loop is the most time-critical or memory consuming part ...

I take that as a given, or otherwise I wouldn't care, myself
(and just write how I feel like, which may casually still involve
StringBuilder)

or if the JIT is able to optimize it well enough.

I doubt it.

claudio (also guilty of sometimes optimizing, when not in need to)

Sometimes it's a question of habit, when I write contrived code,
of which I know from earlier tests that it is indeed more efficient.

e.g.:
cur=it.next(); diff=cur-old; old=cur; doSomething(diff);
which I rather do like this:
doSomething(old-(old=it.next())); //(doSometing() is symmetric)

This change (well, some variant of it) actually once gave
a prog of mine a measurable speedup in overall runtime -
it was iterated almost a billion times, and doSomething
was rather cheap.

Otoh., I'm really lazy, so instead of writing:
for (int i=0; i<5; i++) ...
in non-time-critical and repetitive context, I rather do:
static private final int[] L5={0,1,2,3,4}; // just once
for (int i:L5) ...
despite its worse performance.

 

[Daniele Futtorovic]

Without penalties? What are those two semicolons, then?


Fair enough. Personally, i find the for loop syntax really clumsy.

<snip, snip, snip>

tom

Well, you sure have thought a lot about it. But as my father used to
say: ain't no use crying over spilt sperm.

One thing I'd like to note, though, is that syntactical over-cleverness
in a computer language is -- at least potentially -- a Bad Idea (tm).
IMHO Java derives[1] much of its strength from the fact that it is
rather clumsy and rigid. But rigidity leads to clarity, at least when
it's done right, and encourages discipline, which is a very important
factor. As a result, staggeringly complex constructs could be built with
Java, precisely because the building blocks were simple.

[1] ...or rather derived. It's past the critical mass by now, so that it
can rely on weight (and incumbent PR) rather than on quality. Thence the
autoboxing.

 

[Mike Schilling]

This:

int place ;
while ((place = s.indexOf(x)) >= 0 ) ...

Can be written:

for (int place; (place = s.indexOf(x)) >= 0 ...

Or

for (int place = s.indexOf(x); place >= 0; place = s.indexOf(x))

Which isn't bad except for the redunancy in the first and third clauses.

 

[Roedy Green]

void myMethod() {
doSomething();
{
int foo = 10;
while (foo < 100) {
foo = nextFoo(foo);
}
// foo is not in scope here.
doSomethingElse();
}

The problem you need an ugly extra pair of {}, which even in your case
failed to balance. Figuring out nesting and fixing broken nesting is
by far the syntax feature of Java what wastes the most of my time and
the one that I find hardest just to eyeball.
I suggest some ways out in my Scid project. See
http://mindprod.com/project/scid.html

 

[Roedy Green]

int x = (int y = 1) + 1;

Isn't legal. This:

Why not? I am not asking about the language as defined now, but what
the language designers might have been thinking when they concocted
the syntax.