> -----Original Message-----
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 12, 2003 12:17 PM
> : - role
> : A collection of methods to be incorporated into a class sans
>
> A role can also supply one or more attributes.
So a role can constrain values and add behavior and attributes. Presumably
it can do both at the same time?
enum ParityMode values <P_ODD P_EVEN P_NONE>;
role Byte
does Int[0..255] # Value constraint
does { # extending by adding attributes & methods, and by
overriding the STORE method
has ParityMode $.parity_mode = NONE;
has bit $.parity;
# .CONFORM is redundant with Value constraint above,
which autogenerates this.
method CONFORM(Int $i) { SUPER && 0 <= $i <= 255; }
method STORE(Int $i: $v) { $i = .CONFORM($v) || fail; set_parity; }
method set_parity {...}
};
> : inheritance (and maybe some other stuff, too). Used
> with C<does>.
>
> Here it gets a little fuzzier. A role can be applied to a class
> at compile time via "does", or to an object at run time via "but".
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";
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.
Which is it, by the way? Or is there MTOWTDI, such as a method modifier for
specifying polymorph behavior?
method CONFORM is wrapped { ... 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];
> 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);
> 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
=Austin
