From: Trans <transfire@...>
Date: 2007-01-04T10:33:12+09:00
Subject: Re: Little Things


dblack@wobblini.net wrote:
> On Thu, 4 Jan 2007, ara.t.howard@noaa.gov wrote:
> > hmmm.  there is no way around this kind of thing unless the operation of
> > sending a message to an object is removed from the object's interface.  so we
> > could have something like
> >
> >  Pervasives.send obj, message, *args, &block
> >
> > here Pervasives is an object that cannot be changed - even by changing
> > Object#send.
> >
> > this also allows
> >
> >  Pervasives.object_id obj
> >
> > etc.
> >
> > thoughts?
>
> I'm afraid I'm lost.  What's wrong with send, other than its
> commonness as a name (which is dealt with by __send__)?  If it's too
> much trouble to explain, that's OK.

Precisely right -- both of you -- it just depends on your viewpoint:

1) There should be a unalterable means of dynamically sending a message
to an object. PERIOD. That seem reasonable, but...

2) one can argue #1 is rather non-OOP like and if someone wants to
monkey with the "send" method then that's their silly business.

So we have a choice, do we deviate from strict OOP, or do accept the
dangers of overridablity and recognize that generalized meta-code which
we except to work in all cases certainly will not.

Presently Ruby has adopted the 2nd approach, and uses the #send method
to do it. Unfortunately this method makes the danger of overridablity
even worse b/c, as David points out, it is also a rather common word.
So what happens? To mitigate the danger we get #__send__. This gives
some reassurance of guaranteed sendability while still being
overridable if absolutely necessary. Right? Unfortunately NO! It just
exacerbates the issue further. Not only is there's really no point to
using #send since all assurance rests in __send__, but the assurance
itself is an illusion b/c __send__ can be overridden. We've gained
nothing by this but additional complexity.

So we have a choice. Either pick option #1 instead. Or stick with #2
and choose a single method name that is relatively uncommon.

If Ruby sticks with #2 were actually in luck, there's already a
unspoken precedence for important meta-methods to stay out of the way
of common names, namely those prefixed with object_ (as in object_id)
and instance_ (as in instance_variable_get) One for public sending
(object_send) and one for private sending (instance_send) --at least in
MHO.

One last thing. Has anyone considered a magic dot notation to act as
sort of a window to private space? Eg. something like:

  obj.private.message

T.