--- Larry Wall <[EMAIL PROTECTED]> wrote:
> 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);
Forgive me, I'm trying to get accustomed to the new syntax, so let me
rewrite
> : if $me.away {
> : if $visitor.nephew {
> : $Spot = $nicedog;
> : } else {
> : $Spot = $meandog;
> : }
> : }
as
$Spot = $visitor.nephew ?? $nicedog :: $meandog;
Which brings up a small side note: that's a successfully applied
boolean context for $visitor.nephew, right?
> : 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.
lol -- yeah. This is the kind of code I find six months after writing
it and wonder what sort of delerium I was suffering that day.
So what exactly does it mean to have a "typed reference"? $meandog
still a Dog, just using an AttackDog role, right? So it's type is
Dog&AttackDog? Inheritance thinking starts crowding in here and
blurring my understanding of what's going on.
> Certainly when the Dog object's class is composed, it
> will have to do something about the conflicting .seeVisitor methods
> in the two roles.
Ah! The class has to reconcile the roles used to build it.
That would cause the same conflict between AttackDog.Bark() and
LapDog.Bark(), if each had one, but that certainly falls back to a
matter of design, and that there are better ways to build it.
I wish I had generated a better example, but for the sake of
consistency, I'll work with what we've already got, so how about
predefining defaults to resolve known conflicts?
class Dog does LapDog {...};
Dog.bark is default(LapDog); # I lowercased .bark() here
class Dog does AttackDog;
my Dog $Spot = Dog.new();
$Spot.bark(); # yip, yip....
$Spot.AttackDog.bark(); # sick 'em!
I just noticed I had uppercased my method(s), and it was annoying me.
Anyway, that syntax looks really freaky to me. I can look at it and
know what it was *meant* to do, but how would it be implemented?
Dog.bark but= LapDog;
didn't look any better, though. :(
Obviously I'm not awake yet, but maybe these rambles will be useful to
somebody?
> It might well be better to encode that choice as
> part of the dog's state rather than in the references to it.
I'd say that was almost guaranteed to be the better way to go in
practice. I've just seen too many cases where I was handed poorly
designed legacy code and expected to hack it into some new
functionality, "oh and we need that by three today?"
My workplace considers refactoring to be reinventing the wheel. Just
add another motor and axle over here!! sheesh, lol....
> 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.
And since the type of the ref could be Dog&LapDog&AttackDog&Pet, that
should work. :)
> : And btw, just a refresher on this "assigning a ref" thing -- would
> : the syntax have to change at *all*?
>
> Dunno. I don't see anything obviously wrong with it, but then I
> never could see very well...
Yeah, right. :)
> Larry
Paul
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
