HaloO,
On Wednesday, 14. October 2009 12:18:30 Ovid wrote:
> You *could* (this wasn't explained in the paper) extract those
> methods into C::x(), check your callers and dispatch as appropriate, but
> that would get very problematic, particularly with roles composed of other
> roles.
I consider the dependence of T1 and T2 on their respective public
method implementation a design flaw of these methods. They should
each have a private service routine that in turn is called by the
public x method. But here is how this can be worked around in C:
role T1
{
method foo { self.x }
method x { say "T1" }
}
role T2
{
method bar { self.x }
method x { say "T2" }
}
class C does T1 does T2
{
enum Source <other from_foo from_bar>
has Source $!source = other;
method foo { self!source = from_foo; T1::foo }
method bar { self!source = from_bar; T2::bar }
method x
{
given self!source
{
when from_foo { T1::x; self!source = other }
when from_bar { T2::x; self!source = other }
default { say "C" }
}
}
}
I admit that this is clumsy. So we need an automatic procedure
and some nice syntax. But it looks to me as code analysis of T1
and T2 is needed to generate the wrappers in C.
One point I don't like in the paper is that freezing methods
can be used to erase methods from a role. This is diametrically
opposed to the intent of roles to make a guaranty to provide
an interface.
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
