Paul Hodges writes:
> Larry Wall writes:
> > Perl 5 didn't allow exportation of lexicals because typeglobs only
> > dealt with package variables, not lexical variables. In Perl 6
> > we'll be able to alias both lexicals and package variables. That
> > implies that a lexically scoped name can be exported, whether it
> > refers to a variable or something else like a property.
>
> So a role defined in one module can be scoped lexically so as not to
> trample another module's namespace, and the use()'er of that module can
> elect whether ot not to export that role into his own space for
> implicit use on other objects. Accordingly, if Foo implements a zippy
> property, and Bar does as well, and both are polite enough about it to
> make then the equivelent of EXPORT_OK, then I can say
>
> use Foo 'zippy';
> use Bar;
> use Baz;
>
> my Baz @ray = ( Baz.new() );
> $ray[0] but= zippy;
>
> But just for the sake of clear understanding, suppose I pushed onto
> @ray a whole passle of Foos and Bars and Bazzes. All the Foos and
> Bazzes could use Foo's zippy. If I say
>
> push @ray, Bar.new();
> $ray[-1].zippy = "woohoo!";
>
> then Bar's zippy would be used by default, right?
I think so. If Bar has a zippy method, then that zippy method is called
instead of setting the property. Which are really the same thing. So,
um, yes.
> Now the hard question.
>
> my $tst = Baz.new();
>
> How do I set a zippy property on $tst explicitly using Bar's zippy?
Probably just
$tst but= Bar::zippy;
I imagine that properties work just like other names, so they can be
stuck in package symbol tables, too.
> Is that possible? Baz has no zippy, so I'd have to use "but", right?
> How about
>
> $tst but= Bar.zippy; # is zippy a class property?
> $tst but= Bar::zippy; # is zippy a class method? do I need a & ??
Yeah, the latter one. Note that class methods are called like:
Bar.zippy;
now, so there's no ambiguity. Hooray.
> Or is this even possible?
Please, we're talking about Perl... :-)
Luke
