That's not inconsistent; you're just not understanding. Matz posted
about this some time back and its a perfectly clear and consistent
way of working. Let's say you have an empty Array, 'a':
a =
a[0] # nil
a[1] # nil
That's as expected. So why does this do something that you don't
expect?
a[0..3] #
a[1..3] # nil
Well, it's easier to look at with a non-empty array. Let's try:
a = %w(a b c)
a[0] # a
a[1] # b
a[2] # c
a[3] # nil
Okay, that again is as expected. But where do the indexes point?
According to matz, the indexes are conceptually *between* elements.
Something like:
a b c
0^ 1^ 2^ 3^..
So when you start your range outside of the allowable indexes (and
the size of the array is an allowable, but empty, index), then
you'll get +nil+ from the # call. So for our above array, a[0..3]
produces the expected result, a[3..9] produces an empty array, and
a[4..9] produces nil.
It's regular. It's explained. It makes sense. It just doesn't work
like a P language. I doubt you'll find many experienced Ruby
programmers -- or novice Ruby programmers who don't expect Ruby to
act like a P language -- who are confused about this issue.
-austin
···
On Tue, 22 Feb 2005 00:31:42 +0900, Navindra Umanee <navindra@cs.mcgill.ca> wrote:
Austin Ziegler <halostatue@gmail.com > wrote:
On Mon, 21 Feb 2005 06:07:58 +0900, Navindra Umanee >> <navindra@cs.mcgill.ca > wrote:
Often think it would be nice if "" and 0 were treated like nil.
Such functions could then return "". Heck, NilClass.to_s and
NilClass.to_i already return "" and 0 respectively.
I'm far happier that they aren't.
Maybe what is more annoying, is this type of inconsistency:
I didn't miss this "feature" either. I suspect that an unfinished
transition from Perl to Ruby makes people voice such whishes...
or an unfinished transition to smalltalk/python
I don't like the idea of letting objects decide if they are true or not, but it may have some use cases (i.e. for proper proxy objects)
That's not inconsistent; you're just not understanding. Matz posted
about this some time back and its a perfectly clear and consistent
way of working. Let's say you have an empty Array, 'a':
Thanks for the explanation!
It's regular. It's explained. It makes sense. It just doesn't work
like a P language. I doubt you'll find many experienced Ruby
programmers -- or novice Ruby programmers who don't expect Ruby to
act like a P language -- who are confused about this issue.
I don't really understand why you bring up P languages. It's complex
and unexpected behaviour that you have explained the cause of, but I
fail to see why this particular Ruby Way is more useful or desireable.
Seems mostly like an implementation detail to me but it's good to know
there is an explanation. I probably missed the point.
withImaginaryHungryNilConstruct do
while(line = gets.chomp )
# do stuff with line
end
end # here NilClasses's definition reverts back to normal
You could do this in Ruby now, the only problem being is it would have
dynamic and not lexical "scope" if I may obscenely misuse a term. This
could be quite useful, I imagine, especially if it was generic (eg.
have a way of saying use these modifications for class X for the
duration of this block).
···
On Tue, 22 Feb 2005 00:27:59 +0900, Bill Kelly <billk@cts.com> wrote:
From: "Christian Neukirchen" <chneukirchen@gmail.com>
>
> Sometimes, I'd like an "eating nil" that returns itself for each
> method call, and is false.
>
> Then, stuff like that would be possible
>
> while line = gets.ignore_if_nil.chomp
> ...
> end
>
> Maybe just a crazy idea...
class NilClass
def method_missing(meth_id, *args); self; end
end
?
ObjectiveC's nil works this way.
The downside is you don't find out as early when you
received an unexpected nil, in situations where you
would have preferred to be notified.
Yes, and you wanted a nil that eats its messages silently. So it would
also eat chomp. I meant, if you have a all eating nil then
nil.ignore_if_nil.chomp === nil.chomp.
Regards,
Brian
···
On Tue, 22 Feb 2005 00:48:42 +0900, Christian Neukirchen <chneukirchen@gmail.com> wrote:
Brian Schröder <ruby.brian@gmail.com> writes:
> On Tue, 22 Feb 2005 00:14:41 +0900, Christian Neukirchen
>> Then, stuff like that would be possible
>>
>> while line = gets.ignore_if_nil.chomp
>> ...
>> end
>>
>> Maybe just a crazy idea...
>
> What would the ignore_if_nil call in your example do? Wouldn't the
> above be equivalent to
>
> while line = gets.chomp
> ...
> end
I don't really understand why you bring up P languages. It's complex
and unexpected behaviour that you have explained the cause of, but I
fail to see why this particular Ruby Way is more useful or desireable.
Seems mostly like an implementation detail to me but it's good to know
there is an explanation. I probably missed the point.
I have always had the feeling that there were interesting use cases
for this, but I have never known an example. It's a bit of behavior
that I've just learned to accept via Matz's explanation. In short,
I'm used to it.
This is in contrast to the fact that certain bang methods sometimes
return nil -- that behavior I've also seen justified, and can easily
imagine use cases, but I still have never liked it. It's one of my
most common bugs, personally. And not once have I ever *wanted* the
"return nil" behavior.
withImaginaryHungryNilConstruct do
while(line = gets.chomp )
# do stuff with line
end
end # here NilClasses's definition reverts back to normal
You could do this in Ruby now, the only problem being is it would have
dynamic and not lexical "scope" if I may obscenely misuse a term. This
could be quite useful, I imagine, especially if it was generic (eg.
have a way of saying use these modifications for class X for the
duration of this block).
> On Tue, 22 Feb 2005 00:14:41 +0900, Christian Neukirchen
>> Then, stuff like that would be possible
>>
>> while line = gets.ignore_if_nil.chomp
>> ...
>> end
>>
>> Maybe just a crazy idea...
>
> What would the ignore_if_nil call in your example do? Wouldn't the
> above be equivalent to
>
> while line = gets.chomp
> ...
> end
gets returns nil on EOF.
Yes, and you wanted a nil that eats its messages silently. So it would
also eat chomp. I meant, if you have a all eating nil then
nil.ignore_if_nil.chomp === nil.chomp.
I want a special eating nil, not the standard nil eat everything
(because that can get harmful easily).
···
On Tue, 22 Feb 2005 00:48:42 +0900, Christian Neukirchen > <chneukirchen@gmail.com> wrote:
Btw, in case anyone gets the wrong idea, all this complaining just
means I just love Ruby more.
Cheers,
Navin.
···
Hal Fulton <hal9000@hypermetrics.com> wrote:
I have always had the feeling that there were interesting use cases
for this, but I have never known an example. It's a bit of behavior
that I've just learned to accept via Matz's explanation. In short,
I'm used to it.
This is in contrast to the fact that certain bang methods sometimes
return nil -- that behavior I've also seen justified, and can easily
imagine use cases, but I still have never liked it. It's one of my
most common bugs, personally. And not once have I ever *wanted* the
"return nil" behavior.
This is in contrast to the fact that certain bang methods sometimes
return nil -- that behavior I've also seen justified, and can easily
imagine use cases, but I still have never liked it. It's one of my
most common bugs, personally. And not once have I ever *wanted* the
"return nil" behavior.
