> -----Original Message-----
> From: Larry Wall [mailto:la...@wall.org]
> Sent: Friday, December 12, 2003 8:30 PM
> On Fri, Dec 12, 2003 at 05:17:37PM -0500, Austin Hastings wrote:
> : Good. I like the mixin being available at either time. This
> makes properties
> : a lot more useful since I can provided "default" or "normal" values:
> :
> :   role Celebrated
> :     does Date
> :     does {
> :       method celebrated($d) { return $d.date; }
> :   }
> :
> :   class Birthday does Celebrated {
> :     has $.date;
> :   }
> :
> :   my Birthday $d = Birthday.new('February', 29, 2004) but
> : Celebrated('March', 01, 2004);
> :
> :   print "My birthday is celebrated $d.celebrated";

> More generally, you can write the rest of the class knowing that the
> role is there if it's compiled in.

> : I presume that the linear order (compile time) or chronological order of
> : applying roles decides the order in which overlaid methods are
> : C<wrap>ed/overlaid.

> The original Traits paper specifies that it's illegal to compose two
> methods of the same name into the class, and you have to rename one of
> them to get them both visible.  This is why the authors specifically
> rejected mixins, because they hide errors like this.

> As for the relationship of "Trait" methods to other methods
> declarations, an explicit method declaration in the class proper
> overrides the composed methods, while composed methods override
> anything else in the inheritance hierarchy.

> : Which is it, by the way? Or is there MTOWTDI, such as a method
> modifier for
> : specifying polymorph behavior?

> The default way might well be the way specified in the Traits paper.
> However, their underlying language didn't support any kind of multi
> dispatch.  Perl 6 will be able to "multi" any set of names in the same
> namespace as long as the arguments are differentiable by type.  So it
> might be possible to insert a stub method declaration in the class
> proper that says "treat all composed methods of this name as multis".
> That presumes the methods take differing arguments, of course.

> :   method CONFORM is wrapped { ... call ... }

> That would be another way to do it, except that you might still have
> to switch on something to tell it which role method to call.

> : > A property is a simple kind of role that supplies a single attribute.
> : > The type of a property is identical to its role name.  Roles can have
> : > subtypes that function as enums when the subtypes are constrained to a
> : > single value.
> :
> : This seems really clunky for enums. It works okay for boolean, but even
> : doing month-names is going to suck pretty hard:
> :
> :   role Month;
> :
> :   role January   does Month[0];
> :   role February  does Month[1];
> :   role March     does Month[2];
> :   role April     does Month[3];
> :   role May       does Month[4];
> :   role June      does Month[5];
> :   role July      does Month[6];
> :   role August    does Month[7];
> :   role September does Month[8];
> :   role October   does Month[9];
> :   role November  does Month[10];
> :   role December  does Month[11];
> :
> :   role Month does Int[January..December];

> That's why I suggested some syntactic sugar for it.  But I admit that
> treating each enum as a subtype is a stretch.  They could be constant
> methods, for instance.  In any event, the various enum names should
> probably be hidden in the Month role and not be exported by default.

> : > You can use one of these subtypes without specifically
> implying the role
> : name.  So saying
> : >
> : >     $bar but Red
> : >
> : > might give you a value with the property Color.
> :
> : This is smart and helpful. I like it. However, there needs to
> be a way to
> : specify what to do when multiple roles share the same values.
> For example,
> : if I have NeededBy and Estimated roles:
> :
> :   my $birthday = "02/29/2004" but March;
> :   my $ship_date = "01/01/01" but NeededBy(February);

> Conflicts within a class either need to be reported as soon as they're
> spotted, or dealt with by some kind of multi dispatch.  There's no hiding
> or overriding within a composed class.

> : > You can write the corresponding boolean test using the smart match
> : operator:
> : >
> : >     $bar ~~ Red
> : >
> : > and it (smartly) picks out the Color property to compare
> with, provided
> : > it's unambiguous.  You can use that syntax to compare against any
> : > subtype or junction of subtypes:
> : >
> : >     $bar ~~ Redish&Whiteish     # pinkish
> : >
> :
> : Disambiguation?
> :
> :   $bar ~~ NeededBy(February)
> :
> : or
> :
> :   $bar.NeededBy ~~ February

> Certainly the second form should work, unless it blows up because
> there's no NeededBy property.  Not sure about the parens on the first
> form, but there has to be some syntax that makes the type of an enum
> explicit, and that form is probably going to be preferred if the
> second form blows up on non-existent properties.  And the syntax
> needs to support something like

>     NeededBy[January|July]

> so NeededBy::January is probably not going to cut it.