> Luke Palmer:
> # Now, I don't know what Larry has up his sleeve in this
> # respect, but as I see it now, C<is> is too heavily
> # overloaded. As it stands, it means 3 things:
> #
> # (1) Attributing traits
> # (2) Inheriting base classes
> # (3) "Tying" variables
> #
> # Depending on how traits are implemented, (1) and (3) might be
> # unified.
>
> Who's to say they aren't all unified? If a trait is just a sort of base
> class, and an instance of Scalar (the container) is seen as having its
> own (anonymous) class, then all three are one and the same.
Consider this:
my %hash is keyed(Int);
That would require C<keyed> to implement all hash methods, which I'm
not sure it wants to do. Even if it does, how do you make it work
with base classes like C<constant> which I<also> want to change how
it's keyed. For an even clearer example:
my %hash is constant;
my @array is constant;
my $scalar is constant;
Apparently, these are all implemented with the same container, and
should behave identically.
Nope. Traits aren't ties.
----------
sub foo() {...}
sub bar(&code is rw) {
&code = { "Mwahahaha" };
}
bar(&foo);
If traits are inheritance, then this code shouldn't compile. foo() is
not declared rw, so it can't be passed into bar, which is expecting a
sub that's declared rw.
Obviously, bar()'s C<is rw> is referring to the container being
read-write, and not the sub's return value (which C<is rw> would
specify were it on the definition of sub foo()).
Nah-uh. Traits aren't inheritance either.
(As a side note, how I<would> one declare that a sub is expecting a
sub whose return value can be assigned to?)
----------
In conclusion, there should be a different keyword for attributing
traits as for inheritance/tying. Some possibilities:
Inheritance/Tying:
is (assuming traits have something different)
isa
uses
as
is/tied (would work if traits can't be given to entire classes)
Traits:
is
where
The former is more likely to change if anything is.
Luke
