O
Ohad Lutzky
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
class NilClass
def empty?; true; end
end
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
class NilClass
def empty?; true; end
end
Show of hands - who thinks this is bad form?
class NilClass
def empty?; true; end
end
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
class NilClass
def empty?; true; end
end
Ohad Lutzky said: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".
Ohad said: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.
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.
Hi --
(Don't forget Enumerable#reject
Hi --
(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.
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
... in a case like this:
collection.select do |item|
item.respond_to?empty?) and (!item.empty?)
end
Well said.
I agree.
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.
hash_of_lists = Hash.new{|h,k| h[k] = new_list}
hash_of_lists[:key] << 42 if hash_of_lists[:key].empty?
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.