--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > 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);
>
Given that Larry was talking about typing the other day, how about a
"template-style" behavior that would use types and overrides:
class hash {
has type key is Scalar; # Declare the types up front
has type value is Scalar; # Declare the types up front
insert(key $k, value $v) {...}
}
my %hash has key(int)
has value(String); # Run-time type substitution.
%hash{1} = "Foo"; # okay
%hash{"Foo"} = "Bar"; # Error, or String2int("Foo")
This has the advantage of allowing parameterized types in a standard
way, but the potential disadvantage of increasing compilation time, and
maybe increasing executable size. (I'm not sure on the last one...)
> 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
