Larry Wall <[EMAIL PROTECTED]> writes:
> On Fri, Dec 19, 2003 at 10:36:01AM -0600, Adam D. Lopresto wrote:
> : I've been trying to follow the recent discussion on roles and
> : properties and traits and such, but there's something that bugs
> : me. If I understand correctly, adding a role at runtime using but
> : won't override any methods defined by the class itself (but it
> : will override inherited methods). But then if I create a class
> : that has its own method of saying whether it's true or not, does
> : that mean that "but true" and "but false" won't do anything to it?
> :
> : class Complex {
> : has $.real;
> : has $.imag;
> :
[...]
> : Since Complex already has an implementation of whatever method decides whether
> : it's true or not, wouldn't just applying a property be insufficient to override
> : that?
>
> That is a problem, and you'll notice I haven't answered Jonathan
> Lang yet. That's because I've been thinking about this issue all
> week, and I haven't thought of a way around the problem. Which
> probably means that C<but> really does imply the derivation of a new
> class somehow. Which in turn implies that C<but> is probably not
> powerful enough yet, because it might not only bind roles, but also
> new class methods to control those roles. Maybe
[...]
> However we write it, this derivation does do something more like a
> "slatheron" with respect to the original class. However, a single
> such "slather" can apply multiple roles as well as new class methods.
> So all the compositional power of roles is still there within that
> new class. I guess the real power of roles comes from their parallel
> composition into a class, not from being able to apply them one by
> one at run time. So what we need to do is make C<but> apply a new
> class containing some number of collected and rationalized roles
> (usually one). Call it controlled slathering...it lets you use
> inheritance for slathering as it should be, while not forcing you
> to use extra levels of inheritance to mix in multiple roles when
> you should instead be using a composition.
Will this approach allow for the removal of a property? (I'm currently
stuck for a suggested syntax...)
--
Beware the Perl 6 early morning joggers -- Allison Randal
