From: Gavin Sinclair <gsinclair@...>
Date: 2004-05-12T11:24:18+09:00
Subject: Re: Proposal: Object#send(nil) -> self

D.A. Black wrote:
>> I (generally) don't like special cases either, but this doesn't strike
>> me as such.  The way 'date_str.send(nil)' reads to me is literally
>> "send no message to date_str".
>
> I would say "no message" is a very special case of "a message" :-)

OK, I can't argue with that :)

>> I really like the message-passing paradigm, but sometimes ... you've
>> just gotta *not* pass a message :)
>
> There's a meta-thing going on here, though.  You are passing a message
> -- namely "send", which to me has a very strong semantic thrust.  The
> use of nil you're proposing feels to me like "send(no, actually
> pretend I didn't say that)" or something, which just doesn't seem like a
> good substitute for checking conditions and deciding whether sending a
> message (i.e., name of method to be called) is appropriate (or not) in
> the given situation.

Good points.  What about RCR #294, then?  (I know there's a specific forum
for discussing that, but I'd like to know your thoughts in this context.)

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

  class Object
    def identity
      self
    end
  end

So:

  msg =
    case rand(3)
    when 0 then :upcase
    when 1 then :reverse
    when 2 then :identity
    end

  puts str.send(msg)

Forget the triviality of the example.  Is that a good paradigm?

# I know the example could be recoded in a million different ways, but
# those approaches become ugly as the code gets larger.  This is a
# message-passing language, after all.

Cheers,
Gavin