On 1/9/06, Gaal Yahas <[EMAIL PROTECTED]> wrote:
> sub use_ok($module) {
> eval "package {caller.package}; require etc.";
> }
I'd like to see a nice interface to scopes in general. That is, we
would have a "scope object" which would provide access to all the
lexical scopes and the package scope of a particular call. So for
example, "use" might be written this way (handwaving over some details
of course):
macro use ($package, \$args) {
require $package;
$package.IMPORT(caller.scope, *$args);
}
So you could call IMPORT manually with whatever scope object you like
to get custom importation. But there may be something yet more
powerful...
> More generally, how does one write friendly facades that mix in some of
> the functionality of their real modules? (Eg., "IO" in Perl 5 that loads
> many IO::* modules) I am not sure Role composition will always be strong
> enough to do this. For example if a module one wishes to pull in isn't a
> Role :)
Maybe such a thing doesn't exist; i.e. all modules are roles of some
sort. I would like to see an object/module system all based on
composition. The design of Parse::Rule has shown me that it can be
very powerful, and if I didn't have to jump through ugly flaming hoops
to pull it off, that would be all the better.
A module's job is to "contain" things. So maybe you can do the same
thing you do with roles to any module: pull in the things it contains
and selectively override some of them. For example:
module Bar {
our class Foo {
has $.foo;
}
our Foo $FOO;
}
module Baz {
does Bar; # pull in the base module
our class Foo { # override the Foo member
does Bar::Foo; # hmm...
}
# $FOO is now of type Baz::Foo
# but we don't have to declare it;
# that's how overriding works
}
There's also probably a difference between module containment and
namespace levels; i.e. you wouldn't want to pull in the CGI module and
be able to override its Simple member.
Luke
