From: Rob Sanheim <rsanheim@...>
Date: 2007-01-04T13:07:05+09:00
Subject: Re: Little Things

On 1/3/07, Trans <transfire@gmail.com> wrote:
>
> dblack@wobblini.net wrote:
> > 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.

How is this better then having send and the __send alias, along with
the corresponding bang methods?  It seems to me having one method that
means "send a message", and then having one version be the "dangerous"
version is much more obvious then having object_send and
instance_send.

If a ruby newbie tried "send" and saw it fail due to a private method,
I bet once they saw "send!" in the docs or in irb they would
immediately know how it works.  Its aligns perfectly with many other
things in the std lib, and fits perfectly with POLS.

As for protecting from people overriding it, I think having the
underscore forms is enough.  YSYEO ("You'll shoot your eye out.")  I'm
sure there are programs were object_id and other meta-methods  are
overridden.  All you can do is warn people against doing it, test your
code, and of course choose libraries that behave well.


- Rob