enhanced for loop

Discussion in 'Java' started by visionset, May 4, 2007.

  1. visionset

    visionset Guest

    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) {}



    --

    Mike W
     
    visionset, May 4, 2007
    #1
    1. Advertising

  2. visionset

    Stefan Ram Guest

    "visionset" <> writes:
    >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 ); }}
     
    Stefan Ram, May 4, 2007
    #2
    1. Advertising

  3. Stefan Ram writes:
    > visionset writes:
    >> 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.
     
    Jussi Piitulainen, May 4, 2007
    #3
  4. visionset

    visionset Guest

    "Stefan Ram" <-berlin.de> wrote in message
    news:-berlin.de...
    > "visionset" <> writes:
    >>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).

    --
    Mike W
     
    visionset, May 5, 2007
    #4
  5. visionset

    Stefan Ram Guest

    "visionset" <> writes:
    >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.
     
    Stefan Ram, May 5, 2007
    #5
  6. "visionset" <> writes:

    > 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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, May 5, 2007
    #6
  7. visionset

    Chris Smith Guest

    Lasse Reichstein Nielsen <> wrote:
    > "visionset" <> writes:
    >
    > > 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.

    --
    Chris Smith
     
    Chris Smith, May 5, 2007
    #7
  8. visionset wrote:
    > 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
     
    Patricia Shanahan, May 5, 2007
    #8
  9. visionset

    visionset Guest

    "Patricia Shanahan" <> wrote in message
    news:f1gs5n$1n1i$...
    > visionset wrote:
    >> 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);
    }

    --
    Mike W
     
    visionset, May 6, 2007
    #9
  10. visionset

    Lew Guest

    visionset wrote:
    > 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.

    --
    Lew
     
    Lew, May 6, 2007
    #10
  11. visionset

    visionset Guest

    "Lew" <> wrote in message
    news:...
    > visionset wrote:
    >> 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.
    >


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

    --
    Mike W
     
    visionset, May 6, 2007
    #11
  12. visionset

    Daniel Pitts Guest

    On May 6, 3:50 am, "visionset" <> wrote:
    > "Patricia Shanahan" <> wrote in message
    >
    > news:f1gs5n$1n1i$...
    >
    >
    >
    > > visionset wrote:
    > >> 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);
    >
    > }
    >
    > --
    > Mike W


    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.
     
    Daniel Pitts, May 8, 2007
    #12
  13. visionset

    visionset Guest

    "Daniel Pitts" <> wrote in message
    news:...
    >>
    >> 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.


    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.

    --
    Mike W
     
    visionset, May 8, 2007
    #13
  14. visionset

    Lew Guest

    visionset wrote:
    "Daniel Pitts" wrote
    >> 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.


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

    Others would disagree.

    --
    Lew
     
    Lew, May 8, 2007
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Remi Bastide
    Replies:
    5
    Views:
    13,648
    elizas
    Mar 29, 2010
  2. Christian Schlichtherle
    Replies:
    8
    Views:
    484
    John Currier
    Jul 5, 2005
  3. Andrew Koenig
    Replies:
    46
    Views:
    1,015
    Peter Maas
    Feb 24, 2004
  4. Daniel Cotton

    PEP 315: Enhanced While Loop

    Daniel Cotton, Jun 4, 2009, in forum: Python
    Replies:
    0
    Views:
    289
    Daniel Cotton
    Jun 4, 2009
  5. Isaac Won
    Replies:
    9
    Views:
    445
    Ulrich Eckhardt
    Mar 4, 2013
Loading...

Share This Page