On Wed, Apr 21, 2010 at 12:35:11PM -0300, Daniel Ruoso wrote:
> Em Qua, 2010-04-21 às 00:16 -0700, Stefan O'Rear escreveu:
> > Normally, when you write a method call, the definition of the method is
> > entirely in the domain of the receiver's class:
> >     $object.make-me-a-sandwich;  # $object gets to decide what this means
> 
> Actually, this is delegated to the dispatcher, which is composed in at
> least three different parts:
> 
>   1 - The general dispatching mechanism which iiuc, is lexically 
>       defined and which, by default, implements something like:
> 
>     @*current_invocation_candidates = $object.^can($capture);
>     @*current_invocation_candidates.shift.postcircumfix:<( )>($capture);
> 
>   2 - The MRO resolver, which is implemented inside ^can, and is
>       completely internal to the class.
> 
>   3 - The actual routine invocation, which is internal to the actual 
>       method object.

I failed to find this in the spec, would you give a reference?  It looks
very interesting.

> > However, this is not always how things work.
> >     $object.WHAT;  # Larry says that WHAT should return the protoobject
> > WHAT, WHENCE, postcircumfix:<[ ]>, and similar operators have semantics
> > (although not implementation) defined by the language itself.
> 
> Actually WHAT, WHENCE and the like are considered macros, not method
> calls.

S03 calls WHAT et al macros, S02 calls them methods.

This proposal is somewhat related to macros, in that it can be emulated with
them, much as you can emulate user-defined infix operators by macroing them
to ordinary subs.

> Postcircumfix:<[ ]> is actually an operator, not a method, so they are
> always lexically dispatched.

Treating syntactic categories as subs regardless of call syntax is cruft which
could be eliminated with a more general system.

> > Currently, Perl 6 fakes this by having all values inherit from Any or
> > Mu or Cool, which define the basic, overridable versions of these
> > method-like operators.
> 
> Hmm... I never thought of it as a fake, it's a simple fact, every value
> in Perl 6 should derive from Mu, every non-special type is derived from
> Any.
> 
> > This cheat actually works pretty well in a homogeneous environment,
> > but it fails if we have to consider objects from outside Perl 6.
> >     $parrot-array.WHAT;  # Method WHAT not found for invocant of type ...
> 
> This is actually a rakudobug, a $parrot-array should be properly boxed
> into a value that provides a protoobject... Again, .WHAT is not a
> method.

Autoboxing at language boundaries works very badly in the real world.  I
speak as a Blizkost maintainer, where autoboxing is technically required.
I would hate to see Rakudo follow me in the trail of tears.

> > The problem here is that scopes are conflated - WHAT is defined by the
> > language, which is approximately a lexical scope, while methods on an object
> > are in some entirely different scope.
> 
> AFAIU, method dispatch is also lexically controlled - to some extent.

I'd love a Sxx:yyyy on that, sounds like an interesting section.

> > A methodical is an operator which syntactically behaves as a method but is
> > subject to scoping rules.  Methodicals are defined using the ordinary method
> > keyword, qualified with my or our.  (TODO: This seems the most natural 
> > syntax
> > to me, but it conflicts with existing usage.  Which is more worth having on
> > it?)  Methodicals do not need to be declared in classes, but they should
> > generally have declared receiver types.
> > Thoughts?
> 
> Apparently you're trying to override the default dispatching mechanism
> which, I think, is something already supported by Perl 6 (although not
> yet fully spec.

Then perhaps this could serve as the start of a spec.

-Stefan

Attachment: signature.asc
Description: Digital signature

Reply via email to