HaloO,
On Wednesday, 21. October 2009 12:40:06 Mark J. Reed wrote:
> Rather than disallow the composition, I'd say that any class, role, or
> object that does both roles must override the method in question.
The problem that Ovid posed needs to be resolved in the dispatch
tables seen in certain methods of a class. So the solution is not
overriding the offending method x but the calls to it in methods
foo and bar! The interesting thing is that you have to dig that
information out from the source of the roles T1 and T2. I doubt
that a programmer making the dependency mistake also documents it ;)
I've never seen a call graph of a library in any documentation.
> Which takes us back to Jon's branch of the thread: it would be nice to
> be able to declare such an override in a general way that will apply
> to any such composition that doesn't otherwise override it locally.
> But what should that declaration look like?
Here is a direct syntax for the freeze feature of the paper:
class C does T1 does T2
{
freeze T1::x for foo;
freeze T2::x for bar;
method x {...} # for all other methods
}
The implementation is strait forward: on entry to foo and bar
the dispatch table of the invocant is temporarily patched to
contain the right x. After the call the original is restored.
Heretic question: would it make sense to have a method registry
for roles in CPAN? At least for a set of 'standard' modules that
then allow arbitrary role combinations without conflict.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
