From: Hal Fulton <hal9000@...>
Date: 2004-05-13T00:10:03+09:00
Subject: Re: Proposal: Object#send(nil) -> self

Its Me wrote:
> "Gavin Sinclair" <gsinclair@soyabean.com.au> wrote in message
> 
>>Instead of sending (nil) to get the object, what about sending :self or
>>:identity (if :self is a problematic choice of name).  As in (I'll go with
>>:identity for now):
>>Forget the triviality of the example.  Is that a good paradigm?
> 
> 
> It's a great paradigm, in the sense that the "identity" function is quite a
> basic fundamental case in the set of all transformation functions.
> 
> I have seen arguments that it does not belong in Ruby core, but I would be
> quite happy if it were.

Well, I can see that; but I don't accept the idea that nil should
indicate this.

It seems acceptable to me for every object to have a 'self' reader.
(I'm not sure that's doable in current Ruby, and I'm too lazy at the
moment to try it.)

But the basic problem I had with this idea was that even if there is
a "non-message message" (which as DAB pointed out, is itself a message),
I don't see that it should return the value of the object.

I suppose it makes sense if you think of 'obj.x' and then imagine
stripping off the '.x' -- but in the explicit sense of sending a message
via #send, it seems counter-intuitive. Why shouldn't obj.send(nil) just
return nil, for instance? The typical message sent to an object does not
result in that same object or even an object of that class (yes,
sometimes, but not always).

Anyhow, I can see that obj.send(:self) might make a kind of sense, but
I don't know that it would help the original poster. (Was that you??)


Hal