Re: method names in 1.9

Hello

On 13/11/2007, David A. Black <[e-mail]> wrote:
> Hi --
>
> On Mon, 12 Nov 2007, David A. Black wrote:
>
> > I believe that these two things should be exactly equivalent:
> >
> >  obj.blah
> >  obj.send("blah")
>
> Interesting that when I wrote that, I forgot about the private method
> thing :-) But I think the above does actually make sense to me. It's
> the simplest transformation.
>
>
I wonder why this long winded thread did not name the options we want
to name so far.

When sending a message to an object we have two features that we might
want to use:
1 honoring visibility
2 using method_missing

The standart operator . (which is also often described as a method
call) uses both features.
(3) /=1|2/ For dynamic method names one can use eval and . but we
probably want a shortcut built into the interpreter for this case.

(2) send currently does not honor visibility but does use method_missing

With (3) and (2) and the methods lists available through reflection
one can implement (1) - only call visible methods that exist, and (0)
- call only existing methods regardless of visiblity. However,
implementing the resolving order the same as it is in the interpreter
would take some work. Also everybody implementing these options will
name them differently and possibly will make them behave differently
(because they are not interested in emulating what the interpreter
would do if the message were sent but in making their code work with
minimum effort).

So I guess it is desirable to have all four options available in the
interpreter or stdlib and named in a way that is intuitive enough that
it motivates people not to reinvent the methods.

Sure some people shun using visibilty but since it is implemented we
need options both for working "inside" the internals and from the
"outside".

Similarily not using method_missing defeats proxy objects but at some
point one might want to build and manage complex proxy objects, and
options that aid in that may be welcome. Although in such case
checking the method lists may be more reliable than blindly sending
messages and waiting for exceptions that may come from some place
other than expected.

So in my view (3) - equivalent of . for dynamic names, and (1) -
"send" is all that is needed for sure, the rest is uncertain at best.

Naming two methods should not be that hard. While send and send! looks
nice at the first glance it deviates from the use of ! for
self-mutating version of method that return a modified copy of an
object.


Thanks

Michal