From: ahoward <ahoward@...>
Date: 2003-02-04T04:34:45+09:00
Subject: Re: Local variables & blocks

On Tue, 4 Feb 2003, Tom Sawyer wrote:

> On Monday 03 February 2003 09:14 am, ahoward wrote:
>
> > summary :
> >
> >   nil      -> a non-initialized pointer (non assigned to)
> >   defined? -> detects a non-existent pointer (not declared and defined)
>
> i understand. thank you for the deep explination. still:

wasn't directly solely at you! ;-)  just thought i'd point that out!

>
> 	puts x  #--> undefined local variable or method 'x' for....
>
> why not return 'nack'? then #defined? is not needed for trivial cases.

i am still fuzzy on this - let me re-read that thread.

> use of nack for most things would raise an error. which is an important
> distinction to nil. nil, i feel, needs more methods, like .to_f returning
> 0.0, etc. while something like nack would respond to nearly nothing. nil is
> sort of playing double roll of sometimes "nothing" and sometimes
> "non-applicable". likewise we have to do special method checks like defined?
> and respond_to? to compensate.

i agree that 'nil' should respond to absolutely nothing OR be extended because
this violate POLS :

 irb(main):002:0>  [:to_s, :to_i, :to_f].map { |m| puts "<#{ nil.send m }>" }
  <>
  <0>
  NameError: undefined method `to_f' for nil
	  from (irb):2:in `send'
	  from (irb):2
	  from (irb):2:in `map'
	  from (irb):2:in `each'
	  from (irb):2:in `map'
	  from (irb):2


> yes, i've gotten off the main of the topic. sorry. i do see your point though.
> uninitialized dosen't exactly apply.

not really (OT) i think quite a few of the current threads revolve around some
central ideas which keep coming up.

-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
 ====================================