Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
On Fri, 6 Oct 2006, Ohad L. wrote:
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
nil_is_not_a_container.push :bug if nil_is_not_a_container.empty?
-a
Ooh, actually it is bad form. Seeing as rails already defines .blank? to
be aliased to empty? for strings and arrays, and true for nils.
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
Can I wave a different body part at you to register my disgust?
Martin
On 10/5/06, Ohad L. [email protected] wrote:
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
Doesn’t it depend on context? The other responders seem to suggest
that is objectively bad form, with which I can agree (generally), but
in a case like this:
collection.select do |item|
item.respond_to?(:empty?) and (!item.empty?)
end
I might prefer
collection.select do |item|
true unless item.empty?
end
or this (which, though more terse, I personally find less readable)
collection.select do |item|
!item.empty?
end
One of the beauties of the language (for me) is that language
invariants become somewhat less “in” and more “variant”.
On Fri, 6 Oct 2006, Ohad L. wrote:
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
/me raises hand.
David
Hi –
On Fri, 6 Oct 2006, David C. wrote:
or this (which, though more terse, I personally find less readable)
collection.select do |item|
!item.empty?
end
(Don’t forget Enumerable#reject 
But “empty” actually means something, and it doesn’t apply to all
objects. (I mean, it can, if you define it, but it doesn’t make
sense.) I wouldn’t know whether any of these objects were or were not
empty:
10
98.6
String
lambda { puts “hi” }
etc. nil is in that category.
David
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
My hand is up.
It is strange to ask “is your spoon empty?” when there is no spoon…
Regards,
Rimantas
On 06/10/06, David C. [email protected] wrote:
collection.select do |item|
invariants become somewhat less “in” and more “variant”.
You could make it slightly more elegant with an extra function call
collection.select.do |item|
!Array(item).empty? #Could also use !String(item).empty depending
on what item is
end
Farrel
Ohad L. [email protected] writes:
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
FWIW, 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.
See #7 here:
Or the pattern here:
http://www.refactoring.com/catalog/introduceNullObject.html
Odds are it is probably bad form and it’s possible to encapsulate the
reason why you’re testing for empty into a higher-level method of a
domain class upon which you truly could apply the pattern. Better
that domain class than the object, nil, I think.
Jim
On 10/6/06, [email protected] [email protected] wrote:
On Fri, 6 Oct 2006, Ohad L. wrote:
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end/me raises hand.
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 
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
Cheers
Robert
David
–
David A. Black | [email protected]
Author of “Ruby for Rails” [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB’s Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org
–
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
Ohad L. wrote:
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
Put your hands down. Notice that everyone that says it’s bad form is
doing 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.
T.
On Fri, 6 Oct 2006, Trans wrote:
NoMethod error doesn’t count --that IS bad form.
hash_of_lists = Hash.new{|h,k| h[k] = new_list}
hash_of_lists[:key] << 42 if hash_of_lists[:key].empty?
-a
On Oct 6, 2006, at 9:16 AM, Martin C. wrote:
Put your hands down. Notice that everyone that says it’s bad form is
doing so on purely ideological basis. I challenge them to show one
good
practical case where it’s truly “bad”.You’re working on the assumption that violating idiom or convention
isn’t bad. As far as I’m concerned, it’s very bad, because that’s
where the root of many unpleasant and hard-to-find bugs lie.
Well said.
My hand is staying up.
I agree.
James Edward G. II
Put your hands down. Notice that everyone that says it’s bad form is
doing so on purely ideological basis. I challenge them to show one good
practical case where it’s truly “bad”.
You’re working on the assumption that violating idiom or convention
isn’t bad. As far as I’m concerned, it’s very bad, because that’s
where the root of many unpleasant and hard-to-find bugs lie.
My hand is staying up.
Martin
On 10/6/06, [email protected] [email protected] wrote:
collection.select do |item|
true unless item.empty?
endor this (which, though more terse, I personally find less readable)
collection.select do |item|
!item.empty?
end(Don’t forget Enumerable#reject
collection.reject do |item|
item.empty?
end
much better, indeed! Jeez, I love this language.
On 10/6/06, [email protected] [email protected] wrote:
collection.select do |item|
etc. nil is in that category.
Agreed in general. But I’m thinking, ironically, of the NullObject
pattern applied, in this case, to nil. Admittedly, it is a stretch,
and I can’t really make a great case for it (i.e. with an example I’ve
actually USED), but it seems to me that if I needed to evaluate items
in a collection for empty? and didn’t care that maybe some process
somewhere inadvertantly added nil to the collection that this would be
a reasonable solution. Does that sound nuts? Am I asking for trouble?
David
On 2006-10-06, David C. [email protected] wrote:
… in a case like this:
collection.select do |item|
item.respond_to?(:empty?) and (!item.empty?)
end
If the issue is simply that the collection might contain nils (rather
than some more general empty? things) I would just write
collection.compact.select do |item|
...
end
or
collection.compact.select do |item|
item && ...
end
Those examples only deal with a special case, but I’ve never needed to
implement anything more general. YMMV
Regards,
Jeremy H.
On 10/6/06, James Edward G. II [email protected] wrote:
Well said.
My hand is staying up.
I agree.
Well, in spite of my previous arguments to the contrary, I’m going to
have to recind my down-hand and raise it high. Violating convention is
definitely problematic in my view. Thanks for bringing this up.
Cheers,
David
On 10/6/06, Robert D. [email protected] wrote:
/me raises hand.
nils where you expected containers, guess what I think of your code
Sometimes the code your code plays with is not your code.