--- "Adam D. Lopresto" <[EMAIL PROTECTED]> 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.
I tried for weeks before I could download the "traits paper". I finally got it this week, and it has clarified some stuff (good and bad). > 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). I think this is (or should be) false. Traits added to a class cannot conflict (per the paper and $Larry), but traits added at run-time would be a different category. Larry said something about dynamic derivation of a singleton class, etc. > 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? There's the rub, eh? If you define a trait, say "Deaf", that is intended to supercede normal behavior: my $Grandma is NicePerson but Deaf; then it doesn't work. That sort of runtimeness has to be allowed for somehow. One way, obviously, is to make run-time and compile-time separate, but that doesn't work (see prior messages on mod-perl, etc). Another way is declaration (class) versus dynamic composition (per-object). Another way (not orthogonal, btw) would be Larry's notion of declaring what you intend to screw up. > class Complex { > has $.real; > has $.imag; > > ... > > #Actually, how do we define this? > method asBoolean(Complex $self:){ > return $self.real || $self.imag; > } > > > ... > > > then somewhere in a function > > return Complex::new(0,0) but true; Alternatively, think of the "simple" properties not as C<trait> specifications, but as method overrides. In this case, we're dynamically modifying the method table for the object (i.e., dynamically creating a class) such that a given method behaves the way we want: macro true { "&.asBoolean { return 1; }" } Complex::new(0,0) but true; becomes Complex::new(0,0) but &.asBoolean { return 1; } (This is syntactic sugar, not a real macro, because it couldn't handle the C<if $complex.true> form. Maybe a better macro programmer?) > 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 would be pointless, wouldn't it? =Austin