Nil being empty

Show of hands - who thinks this is bad form?

class NilClass
  def empty?; true; end
end

···

--
Posted via http://www.ruby-forum.com/.

nil_is_not_a_container.push :bug if nil_is_not_a_container.empty?

-a

···

On Fri, 6 Oct 2006, Ohad Lutzky wrote:

Show of hands - who thinks this is bad form?

class NilClass
def empty?; true; end
end

--
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei

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

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 10/5/06, Ohad Lutzky <lutzky@gmail.com> wrote:

Show of hands - who thinks this is bad form?

class NilClass
  def empty?; true; end
end

/me raises hand.

David

···

On Fri, 6 Oct 2006, Ohad Lutzky wrote:

Show of hands - who thinks this is bad form?

class NilClass
def empty?; true; end
end

--
                   David A. Black | dblack@wobblini.net
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

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

···

--
http://rimantas.com/

Ohad Lutzky <lutzky@gmail.com> writes:

Show of hands - who thinks this is bad form?

class NilClass
  def empty?; true; end
end

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

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

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

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?

···

--
Matt

I missed this thread until now, so I'll just raise my hand for the "Nil
is neither empty nor full, so it shouldn't respond_to?(:empty?)" side of
the argument.

···

On Fri, 2006-10-06 at 03:21 +0900, Ohad Lutzky wrote:

Show of hands - who thinks this is bad form?

class NilClass
  def empty?; true; end
end

--
Ross Bamford - rosco@roscopeco.REMOVE.co.uk

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.

···

--
Posted via http://www.ruby-forum.com/.

Hi --

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

(Don't forget Enumerable#reject :slight_smile:

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

···

On Fri, 6 Oct 2006, David Chelimsky wrote:

On 10/5/06, Ohad Lutzky <lutzky@gmail.com> wrote:

--
                   David A. Black | dblack@wobblini.net
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

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

···

On 06/10/06, David Chelimsky <dchelimsky@gmail.com> wrote:

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

> 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 :wink:
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 :wink:
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 :wink:

Cheers
Robert

···

On 10/6/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

On Fri, 6 Oct 2006, Ohad Lutzky wrote:

David

--
                   David A. Black | dblack@wobblini.net
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

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

-a

···

On Fri, 6 Oct 2006, Trans wrote:

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

--
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei

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

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 Henty

···

On 2006-10-06, David Chelimsky <dchelimsky@gmail.com> wrote:

... in a case like this:

collection.select do |item|
  item.respond_to?(:empty?) and (!item.empty?)
end

Matthew Harris wrote:

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

Just to throw a wrentch in the clockwork...what would an implementation
of the full? method look like?

Regards,
Jordan

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 Gray II

···

On Oct 6, 2006, at 9:16 AM, Martin Coxall wrote: