From: Michal Suchanek Date: 2007-11-14T00:26:44+09:00 Subject: Re: method names in 1.9 Hello On 13/11/2007, David A. Black 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