On 10/17/07, Robert Dober <robert.dober@gmail.com> wrote:
On 10/16/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> On 10/16/07, Robert Dober <robert.dober@gmail.com> wrote:
>
> > Nevertheless one question remains, where is the border between
> > a += 1
> > a << 3
> > a << ( :a=>42 )
> > a << ?a
>
> For these I'd draw the border at mutating operators.
Reasonable choice I have to admit
<snip>
> > that is weird.
>
> And going a bit too far I would say.
ok that was actually what I wanted you hear saying
>
> Afer all I wasn't even necessarily prepared to push for NilClass#+
But how would you implement
a +=1 for a being nil?
Hmm, let me see
a = [42]
b += a
b << [43] ouch that hurts
maybe
class NilClass
def + obj
obj.clone rescue obj
end
end
Cheers
Robert
···
On 10/17/07, Dirk Traulsen <dirk.traulsen@lypso.de> wrote:
Am 17 Oct 2007 um 16:31 hat Robert Dober geschrieben:
> On 10/16/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> > On 10/16/07, Robert Dober <robert.dober@gmail.com> wrote:
> >
> > > Nevertheless one question remains, where is the border between
> > > a += 1
> > > a << 3
> > > a << ( :a=>42 )
> > > a << ?a
> >
> > For these I'd draw the border at mutating operators.
> Reasonable choice I have to admit
I think this is a reasonable proposal:
class NilClass
def +(obj)
obj
end
end
Can you think of any case in which this poses a problem?
You're right. That's really better.
(You didn't have to look too hard for a problem, did you? Sometimes
I'm blind! )
But in earnest, I really think this would be a good thing to have in
Ruby.
I'm not so sure about the other cases *,- and /. There you would have
to make a not so short list of object classes for which they must be
handled differently.
But not for +, there it is very clear:
nothing + x is always x, independant from the nature of x.
So, as this is universally correct, it could go in Ruby itself.
···
Am 17 Oct 2007 um 21:08 hat Robert Dober geschrieben:
On 10/17/07, Dirk Traulsen <dirk.traulsen@lypso.de> wrote:
> I think this is a reasonable proposal:
>
> class NilClass
> def +(obj)
> obj
> end
> end
>
> Can you think of any case in which this poses a problem?
Hmm, let me see
a = [42]
b += a
b << [43] ouch that hurts
maybe
class NilClass
def + obj
obj.clone rescue obj
end
end
nil is an interesting beast. In one of my projects, I added "each" to
NilClass
class NilClass
def each
end
end
so that I can treat nil returned from IO:select as if it is an empty array.
I like this change personally, and it does make sense to me logically
("doing something on each element of nothing" is equivalent to "do
nothing"),
but does it make sense to everybody? What if somebody fail to capture the
bug
because of this change?
The same question applies to "nil+1". Does it make sense to everybody?
Somebody may say "if nil+1 is 1, then, 1+nil should be 1", then somebody
else may say "how about nil+nil"?
This may eventually become very philosophical discussion, where there is no
single answer...
Am 17 Oct 2007 um 21:08 hat Robert Dober geschrieben:
> On 10/17/07, Dirk Traulsen <dirk.traulsen@lypso.de> wrote:
>
> > I think this is a reasonable proposal:
> >
> > class NilClass
> > def +(obj)
> > obj
> > end
> > end
> >
> > Can you think of any case in which this poses a problem?
>
> Hmm, let me see
> a = [42]
> b += a
> b << [43] ouch that hurts
>
> maybe
> class NilClass
> def + obj
> obj.clone rescue obj
> end
> end
You're right. That's really better.
(You didn't have to look too hard for a problem, did you? Sometimes
I'm blind! )
But in earnest, I really think this would be a good thing to have in
Ruby.
I'm not so sure about the other cases *,- and /. There you would have
to make a not so short list of object classes for which they must be
handled differently.
But not for +, there it is very clear:
nothing + x is always x, independant from the nature of x.
So, as this is universally correct, it could go in Ruby itself.
nil is an interesting beast. In one of my projects, I added "each" to
NilClass
class NilClass
def each
end
so that I can treat nil returned from IO:select as if it is an empty array.
I like this change personally, and it does make sense to me logically
("doing something on each element of nothing" is equivalent to "do
nothing"),
but does it make sense to everybody? What if somebody fail to capture the
bug
because of this change?
I would definitely not make a change like that. First of all, nil
isn't composed of elements, so there's no concept of "each element" of
nil. Second, the answer to your second question is: the program will
almost certainly blow up or silently do something it isn't supposed to
do. That's what happens when you mask bugs It's not a good idea.
David
--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!
Sometimes