On Sat, Dec 13, 2003 at 01:44:34PM -0800, Larry Wall wrote:
> On Sat, Dec 13, 2003 at 12:50:50PM -0500, Austin Hastings wrote:
> : It seems to me there's an argument both ways --
> :
> : 1. Code written in the absence of a role won't anticipate the role and
> : therefore won't take (unknowable) steps to disambiguate method calls. Ergo
> : method overloads are bad.
> :
> : 2. Roles may be written to deliberately supercede the methods of their
> : victims. Method overloads are vital.
>
> I think the default has to be 1, with an explicit way to get 2, preferably
> with the agreement of the class in question, though that's not absolutely
> necessary if you believe in AOP.
So, if we follow the rules in the Traits paper, a role may have no
semantic effect if the object's class already provides the necessary
methods. To *guarantee* that a role will modify an object's behavior,
we need some sytactic clue. Perhaps "shall"?
my Person $pete shall Work;
Whatever methods Work defines will override corresponding methods of the
same name (signature?) in the Person class. (With "will" or "does" just
the opposite is true) And that same idea could extend to roles
overriding roles easy enough:
my Person $pete will Work shall Lead;
$pete.order(); # calls Lead.order
i.e. if the class Person, and the roles Work and Lead all define a
method called order(), then the Lead role's order() will be the one
called.
I'm not sure that "will" works that way, but you get the idea.
WRT to the classes cooperation, should a class be able to say "You
can't override this method"?
method foo is forever { ... }
Seems like it would make it harder for the programmers to debug in the
event of problems. I guess that could be mitigated by clear error
reporting and rampant object introspection.
> : This doesn't take into account role vs. role conflicts (which seem more
> : likely to be serendipitous).
> :
> : Perhaps an "exact signature" rule would work? Such that if the method was an
> : exact replacement, then no error occurs, otherwise it becomes either an
> : error or a multi?
>
> Er, which method?
>
> : Alternatively, perhaps a role must declare its method to be multi or not,
> : and if not then the role's method overloads the original class's.
>
> No, I think the default needs to be such that the class's method is
> expected to dispatch to the role's method. If no such method exists
> then it falls back on the normal role method dispatch. In either case,
> it would almost always be the case that you'd want multimethod dispatch
> to the set of role methods of the same name.
>
> I'm starting to think that any methods declared in roles are automatically
> considered "multi" when composed, whether so declared or not.
Hmm. So that would mean that we'd need a syntax for method replacement
when we wanted it (which we'd need anyway if the method was our smallest
unit of reuse rather than the role) and the only time we would get an
error is when 2 (or more) roles included in a composition have exactly
the same signature. [slight digression, but methods are really
singleton roles aren't they?]
I'm not sure now whether I like idea of "shall" at all now. It seems
better to just have every method of a role declare that it replaces the
same-name method of the class. If the class doesn't want future roles
replacing a given method, then we get an error. Oh, but without "shall",
composition order would matter and there'd be no visual cue at
composition time that a particular role is special. Drat.
Surely we would need a way to do same-signature replacement on methods
too? This would mildly argue against an implicit "multi".
> So whenever you bind a run-time role, the class looks to see if it
> already knows how to do the combination of roles this object wants,
> and if so, the role binding is very fast. Otherwise it creates the new
> composition, checks for conflicts, resolves them (or doesn't), and then
> binds the new composition as the object's current view of its class.
Neat.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
