--- "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
