On Thu, Dec 20, 2007 at 09:20:22AM +0200, Allison Randal wrote:
> Patrick R. Michaud wrote:
> >
> >Of course, in the previous object model I think there was only
> >one place to look, and find_method did the searching.
>
> In the previous model, there was no distinction between subroutines and
> methods. Any method could be called as a subroutine, and any subroutine
> could be called as a method (you would only get a runtime error if the
> first parameter of the subroutine wasn't a PMC). It was horribly wrong,
> and horribly broken.
>
> >My initial
> >reaction is that the right thing to do is to store the method's
> >PMC in both locations. That way it's still possible to distinguish
> >a method from a normal sub or other symbol table entry. If
> >the dispatch always looks in both locations, it might be more
> >difficult to create a symbol in the namespace that isn't also
> >treatable as a method.
>
> The thing I don't like about storing the method in both places is that
> it's not possible to distinguish a normal sub from a method.
>
> But, as long as it's not the default, and users have to specifically
> request it with a flag, I'm happy to provide the feature. (Though I hope
> it will only be used very rarely.)
I agree that storing a method in the namespace should be controlled
with a flag.
> >In order for inheritance to work in grammars, it's vital that
> >regex lookup and invocation be able to work like methods -- i.e.,
> >invoking <abc> within a pattern should be able to find the 'abc'
> >regex in a parent grammar.
>
> If you dispatch it as a subroutine call, it's not going to respect the
> rules of inheritance, which may bite users who expect that calling <abc>
> will have the same effect in all cases.
Correct. PGE already knows how to handle calls made via the method
interface versus those made from a subroutine interface.
> >However, there are also times that regexes act like subs -- for
> >instance, consider the following:
> >
> > module Foo {
> > rule abc { ... }
> > rule def { ... <abc> ... }
> > ...
> > }
>
> Agreed that the lookup is simpler in this case if they are treated as
> subs. Does the Apocalypse/Synopsis specify that when the 'rule' keyword
> is used in a 'module' block that it acts like a 'sub' rather than a
> 'method'?
Synopsis 5 has:
$regex = rx :g :s :i / my name is (.*) /;
* The name of the constructor was changed from C<qr> because
it's no longer an interpolating quote-like operator. C<rx>
is short for regex ...
* As the syntax indicates, it is now more closely analogous
to a C<sub {...}> constructor. In fact, that analogy runs
very deep in Perl 6.
and also later:
* The analogy between sub and regex extends much further.
* Just as you can have anonymous subs and named subs...
* ...so too you can have anonymous regexes and named regexes
(and tokens, and rules):
token ident { [<alpha>|_] \w* }
# and later...
@ids = grep /<ident>/, @strings;
It also says that keyword-declared regexes are officially of
type C<Method>, but notwithstanding this statement the calling
interface will for now remain easier to manage if we have the option
of placing methods into a namespace.
> To a certain extent, you're going to have to perform a little extra
> magic on these calls anyway, to provide a sensible invocant as the first
> argument of the call.
PGE already does this extra magic. :-)
> Flag approved, on the general principle of allowing flexibility to
> compiler writers. I'm thinking of the flag name :namespace, and of
> giving it an optional string parameter of the name to use in the namespace.
Flag approved: +1 (yay!)
Optional string parameter to C<:namespace> : Anytime there's a
namespace or class parameter, I think we have to consider the
possibility of a keyed argument, since the general case is
that namespaces are given by keys, not strings.
Thanks!
Pm
