nil being empty

[Trans]

That's the best example I have yet seen. Thanks for that Ara. Yet
there's still a problem. Your expecting a NoMethodError on nil, just
like I said. That's the thing, there's no other possible issue involved
here. Now I'll grant James' concern that it can make some bugs harder
to track down, but if that's our primary concern then I suggest we get
back to static typing.

Consider further, that ANY EXTENSION WHATSOEVER can have the same
effect. If someone's class X defines #geegee and I add #geegee to
String, one can no long expect String to raise a NoMethodError on
#geegee. So I argue that the bad form is not in using nil.empty? BUt in
expecting such an error, and not addressing it properly.

hash_of_lists = Hash.new{|h,k| h[k] = new_list}
raise AProperError unless hash_of_lists[:key]
hash_of_lists[:key] << 42 if hash_of_lists[:key].empty?

Oh, one more thing. The best way to address the issue raised by James
is to add selector namespaces to Ruby.

T.

 

[ara.t.howard]

That's the best example I have yet seen. Thanks for that Ara. Yet there's
still a problem. Your expecting a NoMethodError on nil, just like I said.
That's the thing, there's no other possible issue involved here. Now I'll
grant James' concern that it can make some bugs harder to track down, but if
that's our primary concern then I suggest we get back to static typing.

Consider further, that ANY EXTENSION WHATSOEVER can have the same effect. If
someone's class X defines #geegee and I add #geegee to String, one can no
long expect String to raise a NoMethodError on #geegee. So I argue that the
bad form is not in using nil.empty? BUt in expecting such an error, and not
addressing it properly.

hash_of_lists = Hash.new{|h,k| h[k] = new_list}
raise AProperError unless hash_of_lists[:key]
hash_of_lists[:key] << 42 if hash_of_lists[:key].empty?

good points. i guess what i'm driving at is this:

the test of whether something is empty or not implies that it might be able to
contain something. so, in my mind, a better question is show a code exampe
where having nil respond to empty? with true helps the code be more
readable/maintainable/correct/whatever. for example

x = nil

if x.empty?
# then what?
end

see, it's the inverse of your problem. one would have to do this for it to be
useful

x = nil

if x.empty?
case x
when Array
...
when NilClass
...
end
end

because knowing it's empty doesn't really help you use - as you are correctly
pointing out in your comments.

so - to the op i guess - why would you do that in the first place and would it
ever really give you a gain over

if x.nil? or x.empty?
...
end

??

-a

 

[dblack]

Hi --

I feel this being an unnecessary generalization.
Probably it is very often not the best way to treat the problem, but
it might as easily be the most elegant.
Instead of raising your hand David, please speak out

The idea of measuring whether or not nil is "empty" is like measuring
whether or not 1001 is "blue", or defining a method called
FalseClass#scan(regex).

Now it would be unfair to ask others for their wisdom without delivering my
own (as small as it might be).

If you define your small little NilClass monkeypatch above because you had
nils where you expected containers, guess what I think of your code
If on the other hand the NilClass Emptyness is integral part of your design,
document it well and go ahead!
Ruby is a Tool not a Religion. (well at least I think so

Since Ruby lets you define or not define nil#empty?, not defining it
is no more "religious", in the sense I think you mean it, than
defining it -- and in general, religious imagery is about as related
to programming as empty? is to nil It's just a discussion about
best practices.


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[Austin Ziegler]

That's the best example I have yet seen. Thanks for that Ara. Yet
there's still a problem. Your expecting a NoMethodError on nil, just
like I said. That's the thing, there's no other possible issue involved
here. Now I'll grant James' concern that it can make some bugs harder
to track down, but if that's our primary concern then I suggest we get
back to static typing.

If I'm expecting to call #empty? I'm expecting to call it on something
where it's meaningful.

What is 0.empty? 1.empty? -1.empty? If I allow nil.empty? why do I not
want Fixnum#empty?

Nil isn't empty: nil just isn't. (As someone else said, one's spoon
can't be empty if one doesn't have a spoon.)

-austin

 

[Austin Ziegler]

Oh, one more thing. The best way to address the issue raised by James
is to add selector namespaces to Ruby.

I doubt it. No silver bullet and all.

-austin

 

[Trans]

That's the best example I have yet seen. Thanks for that Ara. Yet there's
still a problem. Your expecting a NoMethodError on nil, just like I said.
That's the thing, there's no other possible issue involved here. Now I'll
grant James' concern that it can make some bugs harder to track down, but if
that's our primary concern then I suggest we get back to static typing.

Consider further, that ANY EXTENSION WHATSOEVER can have the same effect. If
someone's class X defines #geegee and I add #geegee to String, one can no
long expect String to raise a NoMethodError on #geegee. So I argue that the
bad form is not in using nil.empty? BUt in expecting such an error, and not
addressing it properly.

hash_of_lists = Hash.new{|h,k| h[k] = new_list}
raise AProperError unless hash_of_lists[:key]
hash_of_lists[:key] << 42 if hash_of_lists[:key].empty?

good points. i guess what i'm driving at is this:

the test of whether something is empty or not implies that it might be able to
contain something. so, in my mind, a better question is show a code exampe
where having nil respond to empty? with true helps the code be more
readable/maintainable/correct/whatever. for example

x = nil

if x.empty?
# then what?
end

see, it's the inverse of your problem. one would have to do this for it to be
useful

x = nil

if x.empty?
case x
when Array
...
when NilClass
...
end
end

because knowing it's empty doesn't really help you use - as you are correctly
pointing out in your comments.

so - to the op i guess - why would you do that in the first place and would it
ever really give you a gain over

if x.nil? or x.empty?
...
end

I see your point. And honestly, along those lines I think one could
made a good argument that nil shouldn't be a real object at all, just a
special value. But as things stand it is an object and there is some
precedence for things like #empty? Namely,

nil.to_a
nil.to_s

The core issue is really the dangers of extensions. Let's work on
mitigating those. If we can do that, then we woun't have to be so
concerned with unconventional polymorphisms.

T.

 

[Trans]

That's the best example I have yet seen. Thanks for that Ara. Yet there's
still a problem. Your expecting a NoMethodError on nil, just like I said.
That's the thing, there's no other possible issue involved here. Now I'll
grant James' concern that it can make some bugs harder to track down, but if
that's our primary concern then I suggest we get back to static typing.

Consider further, that ANY EXTENSION WHATSOEVER can have the same effect. If
someone's class X defines #geegee and I add #geegee to String, one can no
long expect String to raise a NoMethodError on #geegee. So I argue that the
bad form is not in using nil.empty? BUt in expecting such an error, and not
addressing it properly.

hash_of_lists = Hash.new{|h,k| h[k] = new_list}
raise AProperError unless hash_of_lists[:key]
hash_of_lists[:key] << 42 if hash_of_lists[:key].empty?

good points. i guess what i'm driving at is this:

the test of whether something is empty or not implies that it might be able to
contain something. so, in my mind, a better question is show a code exampe
where having nil respond to empty? with true helps the code be more
readable/maintainable/correct/whatever. for example

x = nil

if x.empty?
# then what?
end

see, it's the inverse of your problem. one would have to do this for it to be
useful

x = nil

if x.empty?
case x
when Array
...
when NilClass
...
end
end

because knowing it's empty doesn't really help you use - as you are correctly
pointing out in your comments.

so - to the op i guess - why would you do that in the first place and would it
ever really give you a gain over

if x.nil? or x.empty?
...
end

I see your point. And honestly, along those lines I think one could
made a good argument that nil shouldn't be a real object at all, just a
special value. But as things stand it is an object and there is some
precedence for things like #empty? Namely,

nil.to_a
nil.to_s

The core issue is really the dangers of extensions. Let's work on
mitigating those. If we can do that, then we woun't have to be so
concerned with unconventional polymorphisms.

T.

 

[ara.t.howard]

I see your point. And honestly, along those lines I think one could made a
good argument that nil shouldn't be a real object at all, just a special
value. But as things stand it is an object and there is some precedence for
things like #empty? Namely,

nil.to_a
nil.to_s

yes. to_s is kind essential for interpolation, and it even makes sense that
way. to_a is less essential, except for the case of

list = [*nil_obj]

or

send msg, *nil_obj

so one can make good cases for those exceptions, but they are warts.

The core issue is really the dangers of extensions. Let's work on
mitigating those. If we can do that, then we woun't have to be so
concerned with unconventional polymorphisms.

hard to argue with that.

cheers.

-a

 

[Hal Fulton]

If I'm expecting to call #empty? I'm expecting to call it on something
where it's meaningful.

What is 0.empty? 1.empty? -1.empty? If I allow nil.empty? why do I not
want Fixnum#empty?

Nil isn't empty: nil just isn't. (As someone else said, one's spoon
can't be empty if one doesn't have a spoon.)

All agreed.

Maybe the OP is feeling the need for a #nil_or_empty? as others
sometimes have.

I have felt that need, but I defined a null? that returned true
for nil or an empty container.

But that is just silly enough that I wouldn't release any code
that did that.


Hal

 

[Hal Fulton]

Sorry for that thoughtless word, I should have used "strict" instead of
"religious",
David was just amused, my appologies go to those who might have been
offended.
And yes, maybe it was me, who took the thing too serious .

I don't think anyone was offended. The term "religious" is often used
in such a context. But I think it's good to remember that it's a
somewhat tongue-in-cheek usage.


Hal

 

[Seth Thomas Rasmussen]

I'm just not that concerned about the issue.

I could see how it would be handy in some contexts. I could also see
how some of those contexts could have created a more sensible API that
would not have avoided this issue.

Whatever.

 

[Matthew Harris]

I'd like to use the common Python term, "sequence", and ask if a nil
object (None, NULL, whatever some of you call it) is a sequence. What
does nil contain? Nothing, because that's what nil is. It's nothing.
nil is not empty, nor is it full, it's just, #nil?

 

[Hal Fulton]

I'd like to use the common Python term, "sequence", and ask if a nil
object (None, NULL, whatever some of you call it) is a sequence. What
does nil contain? Nothing, because that's what nil is. It's nothing.
nil is not empty, nor is it full, it's just, #nil?

I think/hope we all know that. The point is that there are times
when it feels natural to say: if x.empty?

But circumstances force us to say: if x.nil? || x.empty?
or the equivalent.

The frequency of this idiom has naturally led people to want to
abstract it a little. Some say: if x.nil_or_empty?
and some have said: if x.null?
or the equivalent.

I do agree that making nil return true for #empty? is the
wrong solution.



Hal

 

[Mark T]

Responding to empty? implies that a response to full? is valid.
Which is unlikely with a nil object.
The fact that nil exists is fascinating.
Stepping back one step, I do not like having to deal with it in iteration.
Though I like it as an initial value of objects.
I'm surprised iteration has to deal with nil 'especially'.
I'd like it to be dealt with as a coding stlye-sheet issue.
Possibly I do not use collections enough.
A collection which garbage collects nils might help.

All the best to all.

Markt

 

[Trans]

Responding to empty? implies that a response to full? is valid.
Which is unlikely with a nil object.
The fact that nil exists is fascinating.
Stepping back one step, I do not like having to deal with it in iteration.
Though I like it as an initial value of objects.
I'm surprised iteration has to deal with nil 'especially'.
I'd like it to be dealt with as a coding stlye-sheet issue.
Possibly I do not use collections enough.
A collection which garbage collects nils might help.

All the best to all.

collection = [ nil, :this, nil, :that ]
collection.compact => [ :this, :that ]

T.

 

[Marc Heiler]

"[...] neither Ola Bini nor Martin Fowler consider it necessarily bad
form, depending on your context, i.e. whether it adds to or detracts
from the maintainability of your code."

Surprisingly, with few exceptions, I found that in Ruby its
usually better to go very straight at a problem, and better short
than long... helped me to maintain my own code nicely.

That also means, for me though, that I do agree it is a bit awkward
to ask whether the spoon is full or empty, when there really is
no spoon.

"Then by simple logic, the right solution will be to have it
return false"

I dont think you can apply a lot of logic
on nil at all. Maybe not even a simple logic. ;-)

 

[Mark T]

Is it possible for nothing to exist?
Logically not?
This must have been investigated many times before?

A vacum is not nothing.

Markt

 

[Devin Mullins]

I think/hope we all know that. The point is that there are times
when it feels natural to say: if x.empty?

But circumstances force us to say: if x.nil? || x.empty?
or the equivalent.

Io has a neat idiom for things like this. Whereas a normal message pass is:
size := list size
If you do:
size := list ?size
That's equivalent to:
size := if(list, list size, nil) // that is, if/then/else
What's nice is you can chain it:
size := animal ?limbs ?size
But in this situation, you could create a List isNotEmpty method and:
x ?isNotEmpty ifFalse(...)
Or something.

Devin

 

[Austin Ziegler]

Then by simple logic, the right solution will be to have it return false

No, that's by simplistic logic. This is *not* a boolean situation; nil
is neither full nor empty. Is zero full or empty? Is a scrambled egg
full or empty?

Nil -- and fixnums -- belongs to an infinitely large class of things
which are not-containers. Since they aren't containers, even asking
whether such things are empty is a nonsensical question.

-austin

 

[ara.t.howard]

Then by simple logic, the right solution will be to have it return false

na, read up on godel - every boolean language/situation also has a class of
maybe/unknowable/paradox. this falls there.

-a