On Wed, 29 Jan 2003, Martin DeMello wrote:

> Yes, but my point was, when doing this, I usually have either object
> being an instance variable, or object being assigned shortly before I do
> the call, or object being one of the args to the current method.

'shortly' is subjective though :

  require 'tons_of_stuff'
  object = 42

is this 'shortly'.  alot of namespace polluting could have happened during the
require...

> In the first case, you wouldn't use @object as a block temp variable
> anyway.

why not?

> In the second, you'd have to call object = function_that_sets_object
> within your current method in order to have any expectation of it having
> a value. If you call it after the block, you're fine. If you call it
> before the block, you'll be warned about shadowing.
>
> In the third case, you'll be warned about shadowing.

well.  i guess we disagree on this one.  one of the things i _hate_ about perl
is it's scoping rules, especially how easy it eas to put something into the
global namespace.  i like languages which make it difficult to pollute global
namespaces, take pascal vs C.  i personally think polluting one's parent's
namespace should require effort (not alot) because it is not generally wanted,
if it _were_ every C library in existence would _not_ have been written like :

  static
  int
  function (x)
    int x;
  {
    ...
  }

but i'm with you on not wanting to do this

  x = nil
  loop {
      x = ...
  }

thing all the time.  however, that really seems like the ONLY time one want to
'export' variables isn't it?

-a

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward / fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================