I was working on an assignment for my Algorithms & Data Structures
class when I determined that I had a need to figure out whether an
array was (a) empty, or contained nothing but nils and things that I
want to consider nil, or (b) contained non-nil-esque items. So I was
pleasantly surprised to discover Array#nitems; I thought to myself,
"I'll just make nil-like things respond true to nil?". However, this
didn't seem to work: it appears that Array#nitems checks whether the
array elements == nil, not whether they respond true to nil?. It seems
to me that a nil?-based approach would be more productive, allowing
greater flexibility in terms of what counts as an item.
In case I'm being unclear, if I do
class Thing
def nil?
true
end
end
t = Thing.new
I think it should be the case that [t, nil, 7].nitems returns 1,
instead of 2 as it currently does.
-Eliah.
Eliah Hecht <eliahhecht@gmail.com> writes:
I was working on an assignment for my Algorithms & Data Structures
class when I determined that I had a need to figure out whether an
array was (a) empty, or contained nothing but nils and things that I
want to consider nil, or (b) contained non-nil-esque items. So I was
pleasantly surprised to discover Array#nitems; I thought to myself,
"I'll just make nil-like things respond true to nil?". However, this
didn't seem to work: it appears that Array#nitems checks whether the
array elements == nil, not whether they respond true to nil?. It seems
to me that a nil?-based approach would be more productive, allowing
greater flexibility in terms of what counts as an item.
In case I'm being unclear, if I do
class Thing
def nil?
true
end
end
t = Thing.new
I think it should be the case that [t, nil, 7].nitems returns 1,
instead of 2 as it currently does.
Well, the documentation says "non-nil items", and that means things
that aren't nil. Checking for the exact value nil is quicker than
using a user-defined criterion. #any? and #all? are good for what
you're trying to do.
Eliah Hecht <eliahhecht@gmail.com> writes:
I was working on an assignment for my Algorithms & Data Structures
class when I determined that I had a need to figure out whether an
array was (a) empty, or contained nothing but nils and things that I
want to consider nil, or (b) contained non-nil-esque items. So I was
pleasantly surprised to discover Array#nitems; I thought to myself,
"I'll just make nil-like things respond true to nil?". However, this
didn't seem to work: it appears that Array#nitems checks whether the
array elements == nil, not whether they respond true to nil?. It seems
to me that a nil?-based approach would be more productive, allowing
greater flexibility in terms of what counts as an item.
In case I'm being unclear, if I do
class Thing
def nil?
true
end
end
t = Thing.new
I think it should be the case that [t, nil, 7].nitems returns 1,
instead of 2 as it currently does.
Well, the documentation says "non-nil items", and that means things
that aren't nil. Checking for the exact value nil is quicker than
using a user-defined criterion. #any? and #all? are good for what
you're trying to do.
In that case, what's the point of nil?? I'm not sure what you mean by
"It's just a false predicate"; an object that returns true for nil?
doesn't seem to be false-valued. Does nil? do anything in the
language, or is it just meant to be a convient way to check if
something == nil?
-Eliah.
···
On Sun, 13 Mar 2005 21:37:24 +0900, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Nil is a nil is a nil. Defining nil? to be true doesn't make
something nil. It's just a false predicate.
Yukihiro Matsumoto wrote:
>In case I'm being unclear, if I do
>class Thing
> def nil?
> true
> end
>end
>t = Thing.new
>I think it should be the case that [t, nil, 7].nitems returns 1,
>instead of 2 as it currently does.
Nil is a nil is a nil. Defining nil? to be true doesn't make
something nil. It's just a false predicate.
On another note: Can we perhaps introduce Enumerable#count which returns the number of elements for which the block is true? I know that we can do .find_all { ... }.size, but constructing an Array of all elements just to get its size seems wasteful.
Yukihiro Matsumoto wrote:
>On another note: Can we perhaps introduce Enumerable#count which returns >the number of elements for which the block is true? I know that we can >do .find_all { ... }.size, but constructing an Array of all elements >just to get its size seems wasteful.
enum.inject(0){|i,j| j ? i + 1 : i }
No array construction, bit harder to read than #count.
Is it too rare to deserve a built-in short cut?