Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > No Thing Here vs Uninitialized and RCR 303

Reply
Thread Tools

No Thing Here vs Uninitialized and RCR 303

 
 
Cyent
Guest
Posts: n/a
 
      05-08-2005
I'm observing a general trend in the responses to RCR 303.

The first and most striking is -w. I always, utterly and without fail, use
-w and had assumed incorrectly that everyone else did. (But then I always
use -W -Wall on gcc as well)

This fact I find curious given the storm of but "RCR 303 might mask a bug"
responses.

Now let us consider when a nil does arise in ruby....

Nil arises in several places that I can think of.

The most obvious case, and the case I think most people are concerned
about, is when referencing an uninitialized variable.

This case is flagged by -w, and hence I had mentally disregarded the
possibility when I wrote RCR 303.

The next case is when nil is returned by something like a regex match or
an index out of bounds.

The third case is when explicit set by the programmer, typically as a
default parameter to a method.

The fourth case is to get around the lexical scoping umfeature of rubies
local variables.

def foo
my_var = nil
box.each do |e|
my_var = e if e.blah
end

use_var( my_var)
end

This is another case of "nil means uninitialized".

So what we have is a "nil" is a little too busy, means too much, is
overloaded too heavily.

It means "uninitialized".

It also means "no thing here" (as in return from regexp match (no
MatchData here), index out of bounds (no Array element here), and nil as a
default value.)

I perfectly agree that "uninitialized" should throw a
NoMethodError. Indeed I doubt if it should respond to some of the
methods it does respond to currently. I even think -w is too friendly, I
would prefer it to throw than to just warn.

What I as thinking of by RCR 303 is nil as "no thing here" should respond
to all methods, do nothing and return "no thing here".

So perhaps I should retract RCR 303 and created a new one suggesting and
differentiation between "uninitialized" and "no thing here", and
effectively RCR-303 for "no thing here".

I would welcome suggestions as to how to craft this new RCR.


--
John Carter

The Cybernetic Entomologist - http://www.velocityreviews.com/forums/(E-Mail Removed)

http://geocities.yahoo.com/cy_ent

I'm becoming less and less convinced of humans as rational beings.
I suspect we are merely meme collectors, and the reason meme is only
kept on to help count our change.

 
Reply With Quote
 
 
 
 
Christoph
Guest
Posts: n/a
 
      05-08-2005
Cyent schrieb:
..

>def foo
> my_var = nil
> box.each do |e|
> my_var = e if e.blah
> end
>
> use_var( my_var)
>end
>
>This is another case of "nil means uninitialized".
>
>
>
>

...

>So perhaps I should retract RCR 303 and created a new one suggesting and
>differentiation between "uninitialized" and "no thing here", and
>effectively RCR-303 for "no thing here".
>
>


You could ask for the creation of a separate "undefined" value similar
to the "undefined, "null" pair in Javascript

OT - doses anybody know whatever happen to Javascript 2.0? (please
don't kill me but I actually kind of like Javascript:

/Christoph



 
Reply With Quote
 
 
 
 
David A. Black
Guest
Posts: n/a
 
      05-08-2005
Hi --

On Sun, 8 May 2005, Cyent wrote:

> Nil arises in several places that I can think of.
>
> The most obvious case, and the case I think most people are concerned
> about, is when referencing an uninitialized variable.


That pertains only to instance and global variables, and I don't
remember seeing a lot about it (though I haven't tallied the
responses).

> This case is flagged by -w, and hence I had mentally disregarded the
> possibility when I wrote RCR 303.
>
> The next case is when nil is returned by something like a regex match or
> an index out of bounds.


That seemed to me to be what people were talking about mostly --
things like:

/som(e n)on-matc(hing) regex/.match("blah").captures

> The third case is when explicit set by the programmer, typically as a
> default parameter to a method.
>
> The fourth case is to get around the lexical scoping umfeature of rubies
> local variables.
>
> def foo
> my_var = nil
> box.each do |e|
> my_var = e if e.blah
> end
>
> use_var( my_var)
> end
>
> This is another case of "nil means uninitialized".


It's not that, exactly; rather, you're initializing a variable to nil.
You've chosen nil to represent the initialized state of the variable,
not an uninitialized state. Once you assign to it, it's initialized.

> So what we have is a "nil" is a little too busy, means too much, is
> overloaded too heavily.


I'm not sure where the "too"s come from. How do you determine how
much (or little) use should be made of such a construct? You can
always initialize your variables to something else if you don't like
using nil too much

> It means "uninitialized".
>
> It also means "no thing here" (as in return from regexp match (no
> MatchData here), index out of bounds (no Array element here), and nil as a
> default value.)


It's not exactly "no Array element here"; it's more a default value.
You can have nil as an array element; therefore, it cannot mean that
there's no element. As with hashes, of course, the retrieval of the
default value does not initialize the element:

ruby -we 'a = []; a[3]; p a.size'
0

> I perfectly agree that "uninitialized" should throw a
> NoMethodError.


That's not what happens, though. If a local variable is
uninitialized, you find out before you get to the point of sending it
a message:

bash-2.04$ ruby -e 'a.b'
-e:1: undefined local variable or method `a' for main:Object
(NameError)

whereas NoMethodError happens when you send a message to an object.

> Indeed I doubt if it should respond to some of the
> methods it does respond to currently. I even think -w is too friendly, I
> would prefer it to throw than to just warn.
>
> What I as thinking of by RCR 303 is nil as "no thing here" should respond
> to all methods, do nothing and return "no thing here".
>
> So perhaps I should retract RCR 303 and created a new one suggesting and
> differentiation between "uninitialized" and "no thing here", and
> effectively RCR-303 for "no thing here".
>
> I would welcome suggestions as to how to craft this new RCR.


A few years ago there was a discussion of some kind of NACK mechanism
-- meaning, something that an object could give as a reponse when it
didn't recognize a message, instead of raising NoMethodError. My main
goal was to avoid this:

obj.meth if obj.respond_to?(:meth)

a repetition I've always disliked, and at the same time to avoid
having to do this:

begin
obj.meth
rescue NoMethodError
...
end

The big problem with NACK, though, was that it was incompatible with
method_missing: it offered a different way to handle the same
situation. Anyway, I thought the concept might be of interest in
connection with the problem you're working on, and perhaps you can
engineer it successfully.


David

--
David A. Black
(E-Mail Removed)


 
Reply With Quote
 
James Britt
Guest
Posts: n/a
 
      05-08-2005
Cyent wrote:
> So what we have is a "nil" is a little too busy, means too much, is
> overloaded too heavily.
>
> It means "uninitialized".



nil doesn't 'mean' anything. Assorted code uses nil to express a
condition, and it is the context that confers meaning.

James



 
Reply With Quote
 
Gavin Kistner
Guest
Posts: n/a
 
      05-08-2005
--Apple-Mail-1--182650989
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

On May 8, 2005, at 1:04 AM, Cyent wrote:
[...]
> So what we have is a "nil" is a little too busy, means too much, is
> overloaded too heavily.
>
> It means "uninitialized".
>
> It also means "no thing here" (as in return from regexp match (no
> MatchData here), index out of bounds (no Array element here), and
> nil as a
> default value.)

[...]

Interesting. While I'm not sure I would want the change in Ruby, this
is presumably why Javascript has both the value
'undefined' (uninitialized) as well as 'null' (no value). null ==
undefined, but null !== undefined.
--Apple-Mail-1--182650989--


 
Reply With Quote
 
James Britt
Guest
Posts: n/a
 
      05-08-2005
Christoph wrote:
> You could ask for the creation of a separate "undefined" value similar
> to the "undefined, "null" pair in Javascript
>
> OT - doses anybody know whatever happen to Javascript 2.0? (please
> don't kill me but I actually kind of like Javascript:


Don't worry, there's a secret society of JavaScript, um, ECMAScript[0],
fans here.


Current ECMAScript is edition 3. According to [1]:
"Edition 4 is now expected to be released in Q3 2005. This will update
the standard with respect to the language and the various differing
implementations."


(The likely reality, though, is that browser vendors will continue to
implement whatever they feel best serves them. If that coincides with
recognized specs or standards, so much the better. )

James

[0] http://www.ecma-international.org/pu...s/Ecma-262.htm
[1] http://www.ecma-international.org/ne...final-2004.htm

--

http://www.ruby-doc.org
http://www.rubyxml.com
http://catapult.rubyforge.com
http://orbjson.rubyforge.com
http://ooo4r.rubyforge.com
http://www.jamesbritt.com


 
Reply With Quote
 
Lionel Thiry
Guest
Posts: n/a
 
      05-08-2005
Cyent a écrit :
> I'm observing a general trend in the responses to RCR 303.
>
> The first and most striking is -w. I always, utterly and without fail, use
> -w and had assumed incorrectly that everyone else did. (But then I always
> use -W -Wall on gcc as well)
>


I suppose it's easier to refuse an RCR than to change programming habits.

--
Lionel Thiry

Personal website: http://users.skynet.be/lthiry/
 
Reply With Quote
 
Bill Atkins
Guest
Posts: n/a
 
      05-08-2005
This isn't about changing programming habits. Having nil return nil
for missing methods can have serious consequences.

Consider:

file = create_new_log_file
file.log "here's a bit of information"

You're expecting this code to log something to a file every time it
gets called. But suppose create_new_log_file returns nil, due to some
mistake you've made while coding it. No exception is raised, so when
you run your program, it performs its job appropriately. You move on.

Two months later, you urgently need to get information from those
logs. But uh-oh - the log files are empty. Now you're screwed.

Bill

On 5/8/05, Lionel Thiry <(E-Mail Removed)> wrote:
> Cyent a écrit :
> > I'm observing a general trend in the responses to RCR 303.
> >
> > The first and most striking is -w. I always, utterly and without fail, use
> > -w and had assumed incorrectly that everyone else did. (But then I always
> > use -W -Wall on gcc as well)
> >

>
> I suppose it's easier to refuse an RCR than to change programming habits.
>
> --
> Lionel Thiry
>
> Personal website: http://users.skynet.be/lthiry/
>
>



--
Bill Atkins



 
Reply With Quote
 
John Carter
Guest
Posts: n/a
 
      05-08-2005
On Mon, 9 May 2005, Bill Atkins wrote:

> This isn't about changing programming habits. Having nil return nil
> for missing methods can have serious consequences.
>
> Consider:
>
> file = create_new_log_file
> file.log "here's a bit of information"
>
> You're expecting this code to log something to a file every time it
> gets called. But suppose create_new_log_file returns nil, due to some
> mistake you've made while coding it.


You confirm what I am saying about the difference between "uninitialized
and "no thing here". There should be an explicit difference.

Such a mistake you have presented would typically fill "file" with
"uninitialized", and invoking the log method on "uninitialized" should
throw an exception.

On the other hand, a nifty way of deliberately switching off logging,
without changing a line of the client code would be to stuff "No thing
here" into file, resulting in no thing happening.

That is why I have now withdrawn my RCR, and are working instead on an
implementation of the Nothing class, leaving "nil" to mean
"uninitialized".

It's coming along very nicely thank you, the only sorrow I have at the
moment is to be able to do what I used to with nil takes a bit more
typing....

may_be_nothing = nil

if may_be_nothing
definitely_isnt_nothing( may_be_nothing)
end

now becomes...

may_be_nothing = Nothing.new # I love that
unless may_be_nothing.nothing?
definitely_isnt_nothing( may_be_nothing)
end

ie. "nil" is a Special object in ruby, and the code for handling "if"
statements knows about it. (The RTEST macro in ruby.h)

But hopefully the change conditional to virtual method refactoring will
make most of those instances go away.


John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : (E-Mail Removed)
New Zealand


Surprisingly enough, this email does not originate from a beetle.



 
Reply With Quote
 
James Britt
Guest
Posts: n/a
 
      05-08-2005
Bill Atkins wrote:
> This isn't about changing programming habits. Having nil return nil
> for missing methods can have serious consequences.
>
> Consider:
>
> file = create_new_log_file
> file.log "here's a bit of information"
>
> You're expecting this code to log something to a file every time it
> gets called. But suppose create_new_log_file returns nil, due to some
> mistake you've made while coding it. No exception is raised, so when
> you run your program, it performs its job appropriately. You move on.
>
> Two months later, you urgently need to get information from those
> logs. But uh-oh - the log files are empty. Now you're screwed.


When I see code samples arguing in favor of the status quo, I tend to
think, But you only code it like that because you have certain
expectations regarding nil.

And I think a good part of the argument for changing the current
behavior is that, assuming one is cognizant of the new nil behavior,
people will stop writing code that expects nil to yell at them. (Though
that doesn't address legacy code. Ignore that for the moment.)


However, even assuming a magic wand that instantly grants each coder
sparkling insight into the new behavior, I have a hard time seeing the
overall benefit.

Given the above example, how would one code it with new-style nil?
Explicitly test for nil-ness? Too fugly.

Given Ruby's nature, one might have to test every object on every call,
because who knows what might be touching it and inadvertently setting it
to nil.

For more interesting and useful would be to solve the threading issue
with using nil.blackhole = true inside of blocks or methods where that
behavior is an overall win.

James



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Want to call a custom handler that redirect and receive the http return code (302, 303 or 307) ThunderMusic ASP .Net 1 01-26-2007 04:30 PM
RCR 303: nil should accept missing methods and return nil John Carter Ruby 64 05-19-2005 12:12 PM
wts: Baystack 303 Switches Kevin Wendolowski Cisco 1 10-11-2004 06:43 PM
wts: Baystack 303/301 Kevin Wendolowski VOIP 0 10-11-2004 03:36 PM
Xilinx 6.2 - - WARNING:NetListWriters:303 Rudi Grave VHDL 0 06-09-2004 05:32 PM



Advertisments