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