enhanced for loop

[visionset]

Why did they decide to restrict the variable scope for enhanced for loops?

It is handy sometimes to have the extra scope.

This won't compile:

String[] strings = {"foo"};

String str;

for (str : strings) {}

 

[Stefan Ram]

String[] strings = {"foo"};
String str;
for (str : strings) {}

public class Main
{ public static void main( final java.lang.String[] args )
{ final java.lang.String[] strings ={ "foo" };
for( final java.lang.String str : strings ); }}

 

[Jussi Piitulainen]

String[] strings = {"foo"};
String str;
for (str : strings) {}

public class Main
{ public static void main( final java.lang.String[] args )
{ final java.lang.String[] strings ={ "foo" };
for( final java.lang.String str : strings ); }}

Q. Why is it so?
A. It is so.

 

[visionset]

String[] strings = {"foo"};
String str;
for (str : strings) {}

public class Main
{ public static void main( final java.lang.String[] args )
{ final java.lang.String[] strings ={ "foo" };
for( final java.lang.String str : strings ); }}

I think you miss my point!
It was a question of scope, not how to construct an enhanced for loop
(despite the subject line).

 

[Stefan Ram]

I think you miss my point!

Yes. Sorry.

It was a question of scope, not how to construct an enhanced for loop

I see.

Often the restricted scope will be sufficient.

Otherwise,

for( i = 0; i < strings.length; ++ i )str = strings[ i ];

or

for( final java.lang.String s : args ){ str = s; /* ... */ }

can be used

When the scope is limited, the loop is better decoupled from
its anvironment, which might help to refactor the code, e.g.,
to move the loop to another method.

 

[Lasse Reichstein Nielsen]

Why did they decide to restrict the variable scope for enhanced for loops? ....
String[] strings = {"foo"};

String str;

for (str : strings) {}

What is the expected value of "str" after this?
Why?
What if "strings" was the empty array?

I could see the value being the last value assigned, or null, or
unassigned.

If you want to capture the value, just do:

String str = null;
for(String strx : strings) {
str = strx;
// ...
}

/L

 

[Chris Smith]

Why did they decide to restrict the variable scope for enhanced for loops? ...
String[] strings = {"foo"};

String str;

for (str : strings) {}

What is the expected value of "str" after this?

That's a very good question, in general.

What if "strings" was the empty array?

This seems more obvious to me. Since the array may be empty, the loop
would certainly not result in str becoming definitely assigned. So the
obvious behavior would be that an attempt to use it after the loop in
this case would fail; and if str were definitely assigned before the
loop, it would remain the same.

What's less obvious to me is what to do when the variable is definitely
assigned, and there are elements. In that case, leaving it as the last
element of the array seems like it's letting the implementation leak
through, though I admit it's a minor concern. After all, if one wants
the last element of the array, one should just get it as strings
[strings.length - 1].

The only case where this expanded scope seems both natural and useful is
when one exits the loop with a break statement and later wants to know
what value caused the break.

 

[Patricia Shanahan]

Why did they decide to restrict the variable scope for enhanced for loops?

It is handy sometimes to have the extra scope.

This won't compile:

String[] strings = {"foo"};

String str;

for (str : strings) {}

I think the enhanced for statement deals very simply with some very
simple, but common, cases. It does not have all the "handy sometimes"
features it might have, but anything it does not handle can always be
done using a basic for statement.

Patricia

 

[visionset]

Why did they decide to restrict the variable scope for enhanced for
loops?

It is handy sometimes to have the extra scope.

This won't compile:

String[] strings = {"foo"};

String str;

for (str : strings) {}

I think the enhanced for statement deals very simply with some very
simple, but common, cases. It does not have all the "handy sometimes"
features it might have, but anything it does not handle can always be
done using a basic for statement.

That sums it up nicely, and for sure, it is a very minor concern.

The prompt for the question was the typical way boilerplate code is made
more compact by reusing variables, for example with MenuItems.

MenuItem item;

item = new MenuItem("foo");
menu.add(item);
//...
item = new MenuItem("bar");
menu.add(item);
//...
for (item : blah.createMenuItems()) {
menu.add(item);
}

 

[Lew]

The prompt for the question was the typical way boilerplate code is made
more compact by reusing variables, for example with MenuItems.

MenuItem item;

item = new MenuItem("foo");
menu.add(item);
//...
item = new MenuItem("bar");
menu.add(item);
//...
for (item : blah.createMenuItems()) {
menu.add(item);
}

I would recommend not using the same variable in the loop but using a local
one, unless as Patricia said you need the loop value exposed afterward. There
is too much chance of interaction between code blocks when you don't restrict
the scope of the variable. The times when you should reuse variables in the
way you show are few and narrowly prescribed.

 

[visionset]

I would recommend not using the same variable in the loop but using a
local one, unless as Patricia said you need the loop value exposed
afterward. There is too much chance of interaction between code blocks
when you don't restrict the scope of the variable. The times when you
should reuse variables in the way you show are few and narrowly
prescribed.

Yes I agree, it was just something that cropped up and made me wonder why
they'd forced the declaration.

 

[Daniel Pitts]

Why did they decide to restrict the variable scope for enhanced for
loops?
It is handy sometimes to have the extra scope.
This won't compile:
String[] strings = {"foo"};
String str;
for (str : strings) {}

I think the enhanced for statement deals very simply with some very
simple, but common, cases. It does not have all the "handy sometimes"
features it might have, but anything it does not handle can always be
done using a basic for statement.

That sums it up nicely, and for sure, it is a very minor concern.

The prompt for the question was the typical way boilerplate code is made
more compact by reusing variables, for example with MenuItems.

MenuItem item;

item = new MenuItem("foo");
menu.add(item);
//...
item = new MenuItem("bar");
menu.add(item);
//...
for (item : blah.createMenuItems()) {
menu.add(item);

}

Eeew! I HATE code like that with a passion!

I try my best to create all local references as final, so that I know
that they won't be changed on me somewhere in the code. Your code is
the exact opposite of that goal

Seriously, its bad form to reuse variables. If you have a good enough
IDE (Eclipse, or IDEA for instance) you won't need to use such
dangerous boilerplate code.

 

[visionset]

Eeew! I HATE code like that with a passion!

I try my best to create all local references as final, so that I know
that they won't be changed on me somewhere in the code. Your code is
the exact opposite of that goal

Seriously, its bad form to reuse variables. If you have a good enough
IDE (Eclipse, or IDEA for instance) you won't need to use such
dangerous boilerplate code.

Well for almost all other code I agree, but it has it's place, and I don't
regard it as in the least bit dangerous for the use above. The goal is
compact code to make the long winded process of gui configuration clearer.
Reusing a variable as above says as self documenting code, this is a trivial
local variable thats only merit is inplace config, after which swings
internals take care of tracking the reference. Self documenting code is
good, the code above used as it is, is therefore good.

 

[Lew]

visionset wrote:

Well for almost all other code I agree, but it has it's place, and I don't
regard it as in the least bit dangerous for the use above. The goal is
compact code to make the long winded process of gui configuration clearer.
Reusing a variable as above says as self documenting code, this is a trivial
local variable thats only merit is inplace config, after which swings
internals take care of tracking the reference. Self documenting code is
good, the code above used as it is, is therefore good.

That is, of course, your opinion and you're entitled to it.

Others would disagree.