> -----Original Message----- > From: Larry Wall [mailto:[EMAIL PROTECTED] > Sent: Friday, December 12, 2003 7:39 PM > To: Perl6 > Subject: Re: enums and bitenums > > > On Fri, Dec 12, 2003 at 03:10:30PM -0800, Paul Hodges wrote: > : Ok, wait a sec. Does that mean different references to the same critter > : can have differing sets of aspects? > : > : my Dog $Spot; > : my $doggie = Dog.new(); > : my $meandog = \$doggie.as(AttackDog); > : my $nicedog = \$doggie.as(LapDog); > : if $me.away { > : if $visitor.nephew { > : $Spot = $nicedog; > : } else { > : $Spot = $meandog; > : } > : } > : > : Now, if I'm away and someone show up, I presume that if it's my nephew > : then $Spot.seeVisitor() will invoke the LapDog role's .wag() method, > : but otherwise I expect it to invoke the AttackDog role's .Bark() > : method. I realize there are other ways to get here.... but would this > : *work*??? > > We might be able to make it work, though as you say, there are other > ways to get there, and the chances are that at least one of them will > be a better way. Certainly when the Dog object's class is composed, it > will have to do something about the conflicting .seeVisitor methods > in the two roles.
Hmm. What does that do for run-time behavior? If you have to worry about (essentially) every possible role's namespace conflicting with every other, the whole thing risks getting less useful quickly. > It might well be better to encode that choice as > part of the dog's state rather than in the references to it. Treat 'em as a stack. Last one applied dominates. But make sure there's a way to unstack the roles when finished. > On the > other hand, it might just fall out of our implementation that it does > the right thing with typed references, if the method dispatch to > the conflicting methods in the Dog class can have access to the reference > types to break ties. That's cool.
