Smaller than an object?

I find myself writing snippets of code inside other modules and scripts that look like this:


{    # localize $foo
   my $foo = 0;
   use constant FOO_CYCLE => 23;

   sub note_a_foo {
      $foo++;
   }

   sub check_foo {
      return unless $foo >= FOO_CYCLE;
      $foo = 0;
      do_something_about_foo;
   }
}
[download]

And then elsewhere:


  for (long_loop) {
     ...
     note_foo;
     ...
  }
[download]

The block localizing the $foo counter isn't really an object; what would you call it? I've got enough of these now in my production code that I'd like to have some term for them, like "nugget" or "black box" or "micro-object", so that my documentation for each can be more immediately meaningful to another reader. Is there a commonly used term for such a construct?

-- 
Jeff Boes                            vox 269.226.9550 ext 24
Database Engineer                           fax 269.349.9076
Nexcerpt, Inc.                       http://www.nexcerpt.com
        ...Nexcerpt...Connecting People With Expertise
[download]

Comment on Smaller than an object? Select or Download Code

Replies are listed 'Best First'.
Re: Smaller than an object? by perrin (Chancellor) on Aug 21, 2002 at 19:32 UTC
That's just a closure. The extra block stuff is not necessary unless you have another $foo in the outer scope.	[reply]
Re: Smaller than an object? by Aristotle (Chancellor) on Aug 21, 2002 at 21:04 UTC
That construct, when used to limit the scope of certain variables, is sometimes called an anonymous block - as opposed to one with a label: `NAMEDBLOCK: { # ... # ... }` [download] The functions you declare inside this block are indeed closures as perrin notes. Makeshifts last the longest.	[reply] [d/l]
Re: Smaller than an object? by theorbtwo (Prior) on Aug 21, 2002 at 21:31 UTC
I'd call the outer block a scoping bare block. A "bare block" is the "correct" (in as much as the Camel uses it -- Camel2 pg103) term for a block that isn't part of a looping statement (it's "semanticly equivlent to a loop that executes once"). The "scoping" part just lets us know what it's for -- scoping, not a roll-your-own loop with redo, last, or next. The subs within the block are closures. BTW, I'd use the block around the subs, even if you don't yet have a $foo outside. If you can clearly see a good line of interface, use it. Confession: It does an Immortal Body good.	[reply]
Re: Smaller than an object? by chromatic (Archbishop) on Aug 21, 2002 at 21:39 UTC
I'd call it an object. It's encapsulated data associated with behavior. (Dominus didn't fall for that question in his Iterators and Generators talk.)	[reply]
Re: Smaller than an object? by Abigail-II (Bishop) on Aug 22, 2002 at 11:15 UTC
Some say an object is data that knows which methods apply to it, while closures are methods that know which data to act on. I wouldn't call it an object because you cannot point to it. You can't pass it someone else. The methods however can be pointed at (trivially, they have a name). Abigail	[reply]
Re: Smaller than an object? by erikharrison (Deacon) on Aug 21, 2002 at 19:19 UTC
Counter? I know about as much C as I know Quantum Mechanics, but I believe that this trick corresponds (roughly) to the static declaration, and is a common trick for this sort of problem. Rather than having a general term for the trick, using a term that also points to the variables purpose (like counter) is probably better self documentation. Just put a thorough knowledge of lexicals into your bag of tricks and call it whatever it needs to be called for that bit of code. Cheers, Erik Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet	[reply]
Re: Smaller than an object? by astaines (Curate) on Aug 22, 2002 at 12:33 UTC
My first thought was 'closure' and after thinking some more I feel that this is the right choice. At least in a Perl context these aren't recognisably objects, and I think that it makes life easier if your choice of names reflects the common syntax of the language. Perhaps the key question is what will your successors expect these to be called? 'closure' while standard terminology, might not mean enough to them. Of couse you could document it somewhere in your meta-documentation/coding standards... -- Anthony Staines	[reply]

Back to Meditations