From: Peter Vanbroekhoven <calamitas@...>
Date: 2005-08-30T00:00:11+09:00
Subject: Re: Method behaves differently when called using #send

On Mon, 29 Aug 2005, David A. Black wrote:

> Hi --
>
> On Mon, 29 Aug 2005, Peter Vanbroekhoven wrote:
>
>> On Mon, 29 Aug 2005, David A. Black wrote:
>> 
>>>> The second possibility would be to give methods implemented through 
>>>> method_missing precedence over private methods. Thus without receiver, 
>>>> first a public method is sought for, if not found method_missing is 
>>>> called, if that fails, the private method is called if present. So 
>>>> essentially it tries the call with receiver, then it tries without.
>>> 
>>> I'm not sure I follow this.  If you call a method without receiver, it
>>> would call it *with* receiver first?  Or do you mean "with[out]
>>> receiver" behavior would be redefined?
>> 
>> First off, I have to mention that I meant with[out] _explicit_ receiver, of 
>> course. Every method call has a receiver.
>
> Yes -- really the confusion was in my restatements, not your usage.  I
> too meant "explicit", though even looked at that way I was garbling it
> a bit.
>
> I think I would have problems with what you're describing.  This seems
> odd to me:
>
>  class C
>    private
>    def x
>      "x"
>    end
>
>    public
>    def method_missing(m)
>      "method_missing: #{m}"
>    end
>
>    def y
>      x    # public x? no; method_missing? yes
>           # (never gets to the point of checking for
>           #  private x)
>    end
>  end
>
>  C.new.y   #  "method_missing: x"

Indeed, that was exactly the idea, that in resolving a method call, public 
methods come first, then method missing methods, and then private ones. I 
presented it as an option, but I don't like it much either. I think what 
bothers me most is that method calling becomes too involved. It's asking 
for more trouble than there is now.

> I'm not sure exactly why, but that feels wrong.  More concretely: if
> you tried to call a private method *from* method_missing, you'd get
> into an infinite loop.  So implementations of method_missing would be
> limited.

Good argument. So that option is out I think. I have no variation in mind 
that sails around this and that isn't even more involved.

> I'm working on a mock-up of my ideal vision of this... :-)  I think I
> do feel that no method and forbidden method should be distinguished
> from each other, and that forbidden should be checked before "no".  I
> think.

I agree on this. In Ruby it is definitely something different and could -- 
if not should -- be distinguished.

> [...]
>
>> Of course, same here; it was only meant as clarification. I don't like 
>> fcall myself, though I'm not sure about send! either. Matz is introducing 
>> send! because send as it is now is confusing, it violates POLS (I think 
>> that is appropriate now as I suspect Matz was surprised by send's 
>> behavior). And violating POLS is not the same as being dangerous. Of course 
>> calling private methods could be dangerous. So I think I can understand 
>> Matz's hesitation here.
>
> Matz hasn't decided to introduce send! as far as I know; it's just
> under discussion.

Of course, I was using the name that got most votes, instead of writing 
the full "the method which may be called send! or fcall or whatever". I 
was rather referring to the concept. I can see after reading that 
paragraph again how that is confusing. My bad.

Peter