On Sat, Dec 13, 2003 at 07:16:21AM -0800, Paul Hodges wrote:
: $Spot = $visitor.nephew ?? $nicedog :: $meandog;
:
: Which brings up a small side note: that's a successfully applied
: boolean context for $visitor.nephew, right?
Yes, but $visitor.nephew is no longer .does(nephew) in my current view.
You have to say
$Spot = $visitor ~~ nephew ?? $nicedog :: $meandog;
if nephew is to do any kind of implicit subtype matching. You can also
be explicit with .does(), of course.
: > : 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.
There are going to be some limits on what you can do. We don't have
enough parallel universes to allow all uses of all junction types--in
the absence of quantum computing the combinatorics are not in our favor...
: > 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?
As a example of the problem with defaults, if nothing else. :-)
: > 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....
With multis you can be refactoring while you're also adding motors
and axles. :-)
: > 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. :)
Touché.
Larry
