so on purely ideological basis. I challenge them to show one good practical case where it’s truly “bad”. And no, purposefully expecting a
NoMethod error doesn’t count --that IS bad form.
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.
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
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.)
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.
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).
Yes David I agree 100%, but…
sometimes nil might be a natural model for something considered empty,
anyway I cannot come up with a useful example, all examples I have
seen
seem to indicate that you are right, you, James, Ara, but, but
I have a very great dislike for Dogmas.
Probably we would all, even me recognize a useful example, I dunno.
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.
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 completely see your points and almost agree, thx for explaining.
Robert
–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.
Albert Einstein
–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.
long expect String to raise a NoMethodError on #geegee. So I argue that the
contain something. so, in my mind, a better question is show a code exampe
useful
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.
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.
long expect String to raise a NoMethodError on #geegee. So I argue that the
contain something. so, in my mind, a better question is show a code exampe
useful
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.
That is funny, I gnored it, it almost replaces the problem, because now
I
would say nil.empty? is always - me who hate dogmae - unnecessary,
as we
have
objcet.to_a.empty?
probably full with pitfalls, I guess this discussion might be futile,
coming
from one extreme - which I understand -
“nil cannot be empty as blue cannot be prime” to the other extreme which
I
lile in an irrational way “nil.empty? define it if you like it” and in
between we have 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.
That might be so, but I find your statement that nil should not be an
object
seems much more valuable.
Just another idea to work on
Void.class => Class
Void.instance_methods.empty? => true
NilClass.superclass => Void
NilClass < Object => false
and maybe most importantly
Void.new.object_id => 42
Void.new.object_id => 42, the same 42 as above
and maybe
interception of NoMethodError for Void in string interpolation, hiding
the
ugly part and having the Object Modell cleaner.
Object should change name of course
Just my 0.02c (sic)
Cheers
Robert
T.
–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.
Ruby is a Tool not a Religion. (well at least I think so
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.
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.
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.
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.
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?
“[…] neither Ola B. nor Martin F. 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.
It’s just a discussion about
It’s just a discussion about