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"

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.

> The idea was that when a method is called without explicit receiver, it is 
> first tried as if it had self as an explicit receiver, and if that fails, the 
> private method is called, if there is one. This makes sure that if the call 
> with explicit receiver succeeds, the call without explicit receiver succeeds 
> in exactly the same way. If the one with fails, the one without can still 
> succeed if there is a private method. It makes sure the capabilities of 
> method calls without explicit receiver are a superset of the ones with 
> explicit receiver. So yes, the "without receiver" behavior would be 
> redefined, the "with receiver" behavior stays the same. In my first option 
> (no method_missing for private methods), it is the other way around.

>
>>> I think it's still OK to have two versions of Kernel#send, one that does 
>>> the call as if with receiver, one as if without receiver (which can call 
>>> private methods) -- however you name them. But the confusion is not 
>>> because of Kernel#send; it's because of the semantics of method calls with 
>>> receiver vs without receiver, and changing Kernel#send does not solve 
>>> that. Well, IMHO at least.

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.

[...]

> 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.


David

-- 
David A. Black
dblack / wobblini.net

-- 
David A. Black
dblack / wobblini.net