In the tradition of Mr. Lazzaro, a chart:
For origin of the AUTOLOAD/DISPATCH stuff, see:
http://groups.google.com/groups?hl=en&selm=3E6E853D.9090604%40conway.org
Does this make sense as far as the "Rules of Dispatch”? I’ve included a
few suggestions where capability or sequence was unclear.
Given:
package pkg;
use Xclass qw(foo);
my $x = returns_an_Xclass();
foo $x; # Function-style
$x.foo; # Method-style
foo $x:; # Invocant-style (Is the colon needed?)
The dispatcher looks for:
(FM = Function-style or Method/Invocant-style, only)
##| FM Declaration Note
==+===========================================================
A1| my macro foo
A2| macro pkg::foo See note 0, below
A3| macro *foo
B-| Only for method, invocant styles.
B1| M submethod Xclass::DISPATCH May be at runtime
B2| M method Xclass::DISPATCH “
B3| M method SUPER::DISPATCH “ (SUPER meaning inherited)
C1| my sub DISPATCH
C2| sub pkg::DISPATCH
C3| sub *DISPATCH
D1| multi DISPATCH What's the signature required?
E1| my submethod foo Does this make sense?
E2| submethod pkg::foo Or this?
E3| submethod Xclass::foo Only method, invocant styles.
E4| submethod *foo See note 1, below.
F1| M my method|rule Xclass::foo See note 2, below.
F2| M my method|rule foo See note 2, below.
F3| M method|rule Xclass::foo
F4| M method|rule SUPER::foo (SUPER meaning inherited)
F5| M method|rule *foo See note 3, below.
G1| F my sub &foo See note 4, below.
G2| F sub pkg::foo
G3| F sub *foo
H1| my multi &foo See note 5.
H2| multi pkg::foo See note 5.
H3| multi *foo Requires compatible signature.
I1| M my submethod Xclass::AUTOLOAD
I2| M my method|rule Xclass::AUTOLOAD
I3| M submethod Xclass::AUTOLOAD
I4| M method Xclass::AUTOLOAD
J1| F? my sub AUTOLOAD
J2| F? sub pkg::AUTOLOAD
J3| F? sub *AUTOLOAD
K1| F? my multi AUTOLOAD See note 5.
K2| F? multi pkg::AUTOLOAD See note 5.
K3| F? multi *AUTOLOAD Requires compatible signature.
NOTES
=====
Note 0: macro pkg::foo -- There's no forward declaring macros, because
of the need to modify the behavior of the parser. But can macros be
package scoped? I assume yes, because the act of doing "use pkg;"
causes pkg to maybe get parsed, and if pkg defines macro foo, then
macro foo pollutes the namespace of the user if it doesn't have package
scope. From this, I assume that leaving and re-entering the package
scope should reactivate the macro. Is this also true?
pkg p1;
macro foo ...
pkg p2;
foo; # Doesn't invoke macro
pkg p1;
foo; # Invokes macro.
Note 1: submethod *foo -- Submethods are a little weird, since the
intent is (from A6) a non-inheritable method. Defining C<submethod
*foo> sort of implies defining a non-inheritable method for all objects
(which makes it essentially inherited, although things like SUPER won't
invoke it). This seems like the sort of bizarre, hideously dangerous
thing that was common in p4/5. Is it desired/supported? (I can think of
no use for it.)
Note 2: my method foo -- This is essentially "method with lexical
scope", which boggles my mind. But then it occurred to me that in the
right context (e.g. C<class X { my method foo()...}> this might be the
way to do submethods. Is it? Alternatively, is saying C<my method
Xclass::foo> a legal way to wrench control from the Xclass?
Note 3: method *foo -- This is speculation. A6 says, "Methods and
submethods are ordinarily package scoped". So I'm inclined to wonder
about extraordinary methods. Is this another useless cul-de-sac, or
does the design team have something concrete in mind here?
Note 4: subs named "foo", regardless of signature -- My interpretation
of subs is that there's no multidispatch once the name is matched.
Thus, if a sub with no signature exists in scope, it catches all calls
to that name. While if a sub with a signature exists in scope, it
catches calls to that name with matching signature. Some of Damian's
posts have seemed to me to imply that calls that don't match the
signature of the sub will FAIL, rather than dispatch on multimethods.
This needs clarification.
Note 5: my multi &foo -- Another clarification is needed. A6 says, 'You
can declare "scoped" subroutines by explicitly putting a my or our on
the front of the declaration'. The implication of the following
examples is of C<sub> declarations, strengthened by the explicit
mention of defining scoped macros using C<my>. But, in the interest of
being a pain in the neck, I figured I should request clarification: Can
I define a scoped multi? If so, how? If not, why not? (The "if not" is
somewhat important, given that a huge number of built-ins are going to
become multis. If I can't scope them, how about C<.wrap>ing them? Will
wrappers be scoped?)
