On Thu, Apr 22, 2004 at 02:21:17PM -0500, Abhijit A. Mahabal wrote:
: This is actually a couple of questions:
: 1: can you extend roles by saying: role Set is extended {}
Perhaps. Classes and objects that have already composed the role
would have to be notified that they need to recalculate collisions
and flush any method caches, so it depends on the not-yet-written
notification system in Parrot. But roles are currently implemented
in Parrot as funny-looking classes, so it may naturally fall out of
the ability to extend any open class.
: 2: if yes, does this change variables for which you said $var does Set?
: In other words, is the singleton class like a closure or a first-class
: class?
I could argue that one both ways.
: role Set{
: method add ($elt) { $self.{$elt} = 1 }
That'd be:
method add ($self: $elt) { $self.{$elt} = 1 }
or
method add ($elt) { .{$elt} = 1 }
But you don't get $self for free.
: method remove ($elt) {...}
: method intersection($other where Set) {
: # can I write that as: method intersection (Set $other) ?
Yes.
: return $self.keys.grep { exists $other{$^a} }
grepping a hash?
: }
: }
:
: class Set_class does Set {}
:
: class Collector{
: has %.coins does Set; # brand new singleton class
Might have to be written as run-time rather than declarative:
has %.coins will build { $_ does Set }; # brand new singleton class
: has Set_class %.stamps; # use existing class
: }
:
: my Collector $collector .= new;
: $collector.coins.add(new Coin()); #okay
: $collector.stamps.add(new Stamp()); #okay
:
: # much later during compilation
:
: role Set is extended{ # is this: die if any collision in any class
I believe so.
: method difference ($other where Set) {...}
: }
:
: $collector.stamps.difference(...); # okay
(Okay if the role extension didn't die.)
: $collector.coins.difference(...); # Is that legal?
I think so.
: # In other words, is the singleton class like a closure or like a
: first-class class?
I suspect that roles composed into classes recalculate collisions and
die if necessary. But roles used as mixins simply hide other methods
of the same name, just as they would had the difference method been
in the role in the first place.
So I guess they don't behave like closures. That leaves open the
question of how to write it if you *do* want it to behave like a
closure. I don't think there is anything in the engine currently that
can take a "snapshot" of the class in the closure sense. Perhaps there
needs to be. Or maybe if you want a closure of a class you just
.clone the class.
Arguably, if you're going to add things into a role or class, you should
increment the version number, and just rely on versioning. In that case
you get closure semantics, since objects would know whether they were bound
to the old version or the new version.
Since you can get closure semantics that way, it seems like a good argument
for making role extensions work the other way.
Larry
