Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11343 > unrolled thread

Blocks for scope control

Back to article view | Back to comp.lang.java.programmer

Contents

  Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-15 11:50 -0400
    Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-15 17:10 +0100
    Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-15 17:32 +0100
      Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 11:21 -0800
      Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-16 07:59 +0100
    Re: Blocks for scope control markspace <-@.> - 2012-01-15 09:57 -0800
      Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 11:28 -0800
    Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 11:00 -0800
      Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-15 17:49 -0400
        Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 15:45 -0800
          Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-19 21:54 -0400
            Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-20 08:41 +0100
              Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-20 15:24 -0800
              Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-20 19:30 -0400
                Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-20 15:54 -0800
        Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-16 07:55 +0100
          Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-19 21:16 -0400
            Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-21 13:25 +0100
              Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-21 10:41 -0400
                Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-22 13:03 +0100
    Re: Blocks for scope control Roedy Green <see_website@mindprod.com.invalid> - 2012-01-16 06:09 -0800
      Re: Blocks for scope control Henk van Voorthuijsen <voorth@xs4all.nl> - 2012-01-16 07:03 -0800
    Re: Blocks for scope control Arne Vajhøj <arne@vajhoej.dk> - 2012-01-17 18:43 -0500
    Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-20 11:05 -0800
    Re: Blocks for scope control Gene Wirchenko <genew@ocis.net> - 2012-01-20 12:11 -0800
    Re: Blocks for scope control Arne Vajhøj <arne@vajhoej.dk> - 2012-02-06 21:24 -0500

Page 2 of 2 — ← Prev page 1 [2]

#11377

On Sun, 15 Jan 2012 11:50:32 -0400, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> wrote, quoted or indirectly quoted
someone who said :

>Any thoughts?

I use them fairly often for this construct:
  {
  FastCat sb = new FastCat( 2);
  sb.append( "xxx");
  sb.append( "yyyy");
  thing = sb.toString();
  }

  {
  FastCat sb = new FastCat( 2);
  sb.append( "zzz");
  if ( q )
    {
    sb.append( "aaa");
    }
  another = sb.toString();
  }
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

[toc] | [prev] | [next] | [standalone]

#11379

On Jan 16, 3:09 pm, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
>
> I use them fairly often for this construct:
>   {
>   FastCat sb = new FastCat( 2);
>   sb.append( "xxx");
>   sb.append( "yyyy");
>   thing = sb.toString();
>   }
>
>   {
>   FastCat sb = new FastCat( 2);
>   sb.append( "zzz");
>   if ( q )
>     {
>     sb.append( "aaa");
>     }
>   another = sb.toString();
>   }

Interesting cae, but even here I would be inclined to use a variation
of "extract method":

thing = cat("xxx", "yyyy");

String cat(String... strings) {
  FastCat sb = new FastCat( 2);
  for (String str: strings) {
    sb.append(str);
  }
}

...

[toc] | [prev] | [next] | [standalone]

#11436

On 1/15/2012 10:50 AM, Arved Sandstrom wrote:
> See
> http://stackoverflow.com/questions/1563030/anonymous-code-blocks-in-java
> for a general discussion.
>
> I'm talking specifically about the block by itself: a pair of braces by
> themselves, enclosing some code in a method. On occasion I do run across
> situations where a judicious use of such a block inside a method, to
> restrict variable visibility, is handy.
>
> I almost never see anyone else using these things this way. A block in a
> method always seems to be associated with a control construct or
> exception handling. As any number of references point out, you wouldn't
> expect to see many usages of local blocks, mainly because 99 times out
> of 100 that situation is probably handled best by a new method. But in
> my years of looking at Java it occurs to me that I barely see any use of
> this at all...even where it wouldn't be a bad idea.
>
> Any thoughts?

I can see couple of reasons why it is not used much:

1) The average Java developer is not aware of the possibility.

2) If a method is so complex that this trick has a significant effect
    for avoiding mistakes, then the method should be broken up in
    multiple smaller methods.

Arne

[toc] | [prev] | [next] | [standalone]

#11526

On 01/20/2012 07:34 AM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> { final Button button = new Button(); frame.add( button ); }
>
>    I also use blocks to clarify the scope of a comment
>    (when extracting a method is no better solution):
>
> alpha();
> { /* add a button to the frame */
>    final Button button = new Button();
>    frame.add( button ); }
> beta();
>
>    I teach both the use of omitable [sic] »final« keywords and the
>    use of omitable blocks (which both serve only to enhance
>    readability) in my classes right from the beginnig. In fact,
>    I start to teach /all/ variable declaration and parameter
>    declarations with »final« and later explain when »final« can
>    be removed.
>
>    (Many English dictionaries do not have an entry »omitable« [sic].
>    This word is intended to mean the following above: An omitable [sic]
>    part of the source code often [but not necessarily always]
>    can be removed without changing the behavior of the program.)

Dictionaries frequently do not list all possible inflections of a word. In 
this case they undoubtedly leave it to the normal rules of English to produce 
"omittable" (note the double "t") without a separate entry.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11531

On 20 Jan 2012 15:34:51 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:

>ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>{ final Button button = new Button(); frame.add( button ); }
>
>  I also use blocks to clarify the scope of a comment
>  (when extracting a method is no better solution):
>
>alpha();
>{ /* add a button to the frame */
>  final Button button = new Button();
>  frame.add( button ); }
>beta();

     I dislike block ends at the end of a line.

     I use blank lines myself and comment headers with bigger, oh,
call them "wings".

*
*
* This is a high-level comment.
*
*

code
code

*
* This is a less high-level comment.
*

code
code

* This is a fairly tactical comment.

code
code

* This a block comment.
code
code     && and this is a line comment.
         && Sometimes continued.
code

     I usually do not use wings and rarely use two line wings.  If I
add a lesser comment to a winged comment, I put it after the
after-wing, as in:

*
* This is a less high-level comment.
*
* If you modify this code, check over OtherCode() as well.

>  I teach both the use of omitable »final« keywords and the
>  use of omitable blocks (which both serve only to enhance
>  readability) in my classes right from the beginnig. In fact,
>  I start to teach /all/ variable declaration and parameter
>  declarations with »final« and later explain when »final« can
>  be removed.
>
>  (Many English dictionaries do not have an entry »omitable«.
>  This word is intended to mean the following above: An omitable
>  part of the source code often [but not necessarily always]
>  can be removed without changing the behavior of the program.)

     It was surprising to me that there was apparently no such word of
capable of being omitted.  It turns out that it is irregular.  The
word you want is "omissible":
          http://dictionary.reference.com/browse/omissible

Sincerelyk,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11765

On 1/20/2012 9:32 PM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> alpha();
>> { /* add a button to the frame */
>>   final Button button = new Button();
>>   frame.add( button ); }
>> beta();
>
>    I forgot to mention that there is an old software-engineering
>    principle: »The scope of every identifier should be as small
>    as possible.« Blocks help to realize this.
>
>    Or, let's look at code posted into some other thread recently:
>
> student<freenow12345@gmail.com>  writes:
>>         GOval g = makeCircle(centerX, centerY,radiusOuterCircle ,
>> Color.RED);
>>         add(g);
>>         g = makeCircle(centerX, centerY,radiusMiddleCircle ,
>> Color.WHITE);
>>         add(g);
>>         g = makeCircle(centerX, centerY,radiusInnerCircle ,
>> Color.RED);
>>         add(g);
>
>    With blocks, »g« can be made final:
>
> { final GOval g = makeCircle( centerX, centerY, radiusOuterCircle,  Color.RED   ); add( g ); }
> { final GOval g = makeCircle( centerX, centerY, radiusMiddleCircle, Color.WHITE ); add( g ); }
> { final GOval g = makeCircle( centerX, centerY, radiusInnerCircle,  Color.RED   ); add( g ); }
>
>    this also is more beautiful, because now there is more
>    symmetry between the the three actions, which then allows a
>    possible refactor to:
>
> { final CircleMaker circleMaker = new CircleMaker( g, centerX, centerY );
>    circleMaker.make( radiusOuterCircle,  Color.RED   );
>    circleMaker.make( radiusMiddleCircle, Color.WHITE );
>    circleMaker.make( radiusInnerCircle,  Color.RED   ); }
>
>    (this will probably not solve the actual problem of »student«).
>
>    Or, to tell the story from its end:
>
>    The most important principle is »DRY« - »Don't repeat
>    yourself!«. To do this, we abstract repetitions of the same
>    principle into a single code location using abstractions.
>    But to do this, in turn, we need to be able to see
>    repetitions of the same principle. And to be able to see
>    them, the code needs to be made as symmetric as possible,
>    that is, to do the same thing, the same wording should be
>    used.
>
>    Or in a single line:
>    First, make the repetition obvious, then abstract it.

The rule is OK.

But I consider it a 75% rule. Follow it in 75% of cases
and skip it when it does not make sense.

In this case I think the code became less readable, so I would
not do it.

And I would certainly not do that refactoring as it obfuscates
what the code is doing by hiding the adding to g.

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web