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