[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

No Thing Here vs Uninitialized and RCR 303

Cyent

5/8/2005 7:06:00 AM

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 - cyent@xtra.co.nz

http://geocities.yahoo....

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.
24 Answers

Christoph R.

5/8/2005 8:01:00 AM

0

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

dblack

5/8/2005 11:00:00 AM

0

james_b

5/8/2005 2:18:00 PM

0

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

Gavin Kistner

5/8/2005 2:46:00 PM

0

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.

james_b

5/8/2005 5:24:00 PM

0

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/publications/standards/Ec...
[1] http://www.ecma-international.org/news/4xpr-fina...

--

http://www.ru...
http://www.r...
http://catapult.rub...
http://orbjson.rub...
http://ooo4r.rub...
http://www.jame...

Lionel Thiry

5/8/2005 10:34:00 PM

0

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

Bill Atkins

5/8/2005 10:51:00 PM

0

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 <lthiryidontwantspam@skynetnospam.be> 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....
>
>


--
Bill Atkins

John Carter

5/8/2005 11:39:00 PM

0

james_b

5/8/2005 11:46:00 PM

0

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

Bill Atkins

5/9/2005 12:53:00 AM

0

But Ruby already makes a distinction between nil and uninitialized. Compare:

b + 4
NameError: undefined local variable or method `b' for main:Object

with

b = nil; b + 4
NoMethodError: undefined method `+' for nil:NilClass

In my example, file is certainly initialized - it's just initialized
to nil. If create_new_log_file returns nil, file can't be considered
uninitialized.

On 5/8/05, John Carter <john.carter@tait.co.nz> wrote:
> 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 : john.carter@tait.co.nz
> New Zealand
>
> Surprisingly enough, this email does not originate from a beetle.
>
>


--
Bill Atkins