On Fri, 2004-04-23 at 19:52, Damian Conway wrote:
> Aaron Sherman wrote:
> > Now, I know that the Apoc on modules has not been written, and by that
> > time Larry will have thought of this, but I thought I'd point out that
> > some mechanism will have to exist in modules to indicate not only that
> > they acquire certain subroutines, variables, etc. of other modules, but
> > that they re-export them as their own.
>
> My proposal for that issue is just:
Damian, Larry not to contradict you, but over the weekend, I had an idea
that may help (and might be tangential to the other ways of doing this).
If we have the syntax:
class a { does b; }
for classes and roles, then wouldn't it make sense to say:
module b { sub x() is export {...} }
module a { does b; }
to say that a also exports all of b's exportables (including x). In
theory that should allow a to re-export b in a structured manner,
including tags, etc.
IMPLEMENTATION DETAILS:
In a more general sense, could we say that a role is a module with a bit
of extra class-specific behavior, but the does method is defined inside
of MetaModule, and inherited by MetaRole, and overridden as invalid by
MetaClass? That is:
class MetaModule { method does() {...} }
class MetaRole { is MetaModule; }
class MetaClass {
is MetaModule;
method does() {
throw SyntaxError, "Can only call 'does' in Roles";
}
}
At least logically, though the Meta* gang might be written in Parrot or
be part of the compiler....
This seems to me to be the cleanest way to have module a absorb the
calling interface of module b.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
