Austin Hastings wrote:
> Jonathan Lang wrote:
> > OK: when you call $spot.bark, Trog looks for a "bark" method; it finds
> > two: Tree::bark and Dog::bark. Since both methods have been supplied
> > by roles, $spot has no idea which one to use, and throws an exception
> > to that effect.
>
> I am uncomfortable with this. My understanding has been that the will be
> a compile time error, caught when the class declaration is made. Has
> that changed recently?
I don't know for certain; but I think so. Given the ambiguities that can
crop up with multiple dispatches and signatures, it may not be feasable to
catch all of them at compile-time.
> > As such, the code given above is incorrect. Adjusting for this error,
> > we rewrite Trog as follows:
> >
> > class Trog does Tree but no bark does Dog {
> > method grow() {...};
> > };
>
> Modulo syntax, this is more right, yes.
I'm not familiar with modulo. Also, I'm probably abusing the "but" syntax
like nobody's business here.
> > But in the case of
> >
> > role Dog {
> > method bark() {...}
> > must bark();
> > method threaten must bark() { bark; }
> > }
> >
> > class Toothless does Dog but no threaten() no bark() {
> > }
> >
> > You'd still have a problem, because even excluding threaten doesn't
> > exclude Dog's demand to be able to bark.
>
> "Hit jist haint a dawg ifn hit dont bark."
You've never met my dog.
> But large roles are going to want to say C<must> just once, since (1)
> that makes for easier, more legible documentation; and (2) if chromatic
> is correct, most functionality with roles (smaller than classes, recall)
> will likely be pretty incestuous.
The "must" clause in the above "threaten" method is redundant, an artifact
of cut-n-paste coding. The example would work exactly the same with or
without it.
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
