On Tue, Dec 18, 2007 at 03:52:39PM +0200, Allison Randal wrote:
> Patrick R.Michaud (via RT) wrote:
> >
> >This ticket is asking for some convenient mechanism to have
> >a :method be automatically entered as a sub in the namespace.
> >This used to be the situation prior to the pdd15oo merge,
> >and I've come across some instances in perl6 and PGE where this
> >is really needed.
> >
> >We can either provide a flag to :method that means "also add
> >the method to the namespace", or we could let :method automatically
> >be placed in the namespace unless another flag (e.g., :anon) is
> >present.
>
> I'm trying to decide if the right thing to do is store the method's PMC
> in both locations, or change the dispatch for the call to look in both
> locations.
Of course, in the previous object model I think there was only
one place to look, and find_method did the searching. 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.
> So, a little more background: Is the HLL feature you're
> supporting here the "indirect object" syntax, where you can make a
> method call that looks like a subroutine call, with the object
> (invocant) as the first argument?
No, that's not directly the HLL feature I'm after, although that
will also be easier as a result of this. The specific case I've
run into involves regexes and subrule handling in PGE and perl6.
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.
However, there are also times that regexes act like subs -- for
instance, consider the following:
module Foo {
rule abc { ... }
rule def { ... <abc> ... }
...
}
Here 'abc' can't really be a method, because there's not a class
to which it can be added. So, we need to make sure that 'abc'
gets an entry in the 'Foo' namespace somehow. Things become a lot
simpler overall if PGE can simply generate subs that are methods
and automatically appear in the namespace.
The specific case that prompted the ticket is dealing with
anonymous regexes, as in:
$a ~~ / foo \d+ /;
This again generates a regex that isn't a method in a class, and
the only way to look it up is by its internally generated name.
Prior to pdd15oo, PGE could always generate a regex as a simple sub
without a :method flag and receiving any "invocant" as an explicit
first argument. The regex sub could then be located either via
find_method (to follow inheritance) or by namespace lookup (act as
a simple sub).
After pdd15oo, in order to preserve inheritance PGE switched to
placing :method flags on the subs it generated, and converting
many subcalls to method invocations. But placing :method on
the generated subs also had the effect of removing them from
the namespace, which led to the problems for the non-method
regexes I described above.
It's entirely possible that PGE should have a flag on it that says
"generate a regex method" versus "generate a regex sub", and we
may end up with that anyway. But I can also envision situations
where we'll want to be able to locate methods via namespace entries,
it's much easier to have a compile-time flag to tell imcc to put
a method into a namespace than it is to generate :load :init
instructions to make the mapping. (Or to use PGE's present workaround,
which is to generate a separate :method wrapper around a sub.)
Hope this helps,
Pm
