Gordon,
It just occurred to me that the system shown below could be re-
written to do away with class methods entirely.
class Host {
my $.plugInClass;
}
role PlugIn {
method initWithHost (Host $h:) { ... }
}
role FeatureA {}
role FeatureB {}
role FeatureC {}
class AB {
does PlugIn;
does FeatureA;
does FeatureB;
}
class ABC {
does AB;
does FeatureC;
}
Now later on, instead of asking the PlugIn if it "supportsFeatureB",
you can just see if it does the "FeatureB" role, like this:
if ($host.plugInClass.does('FeatureB')) {
# ... do something with FeatureB
}
This will work with the ABC plugin as well since AB is being treated
as a role, ABC will actually consume all it's subroles, which means
that ABC will DWIM too. In fact, we get even more from this system
since we can check if one plug-in is capable of "doing" another,
because this "just works"
if ($host.plugInClass.does('AB')) {
# ...
}
And since an example is better when it is backed up by working code,
I coded this up using the current meta-model prototype. You can see
it here: http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel/t/
38_PlugIn_example.t
Stevan
On Oct 12, 2005, at 9:41 AM, Stevan Little wrote:
class Host {
my $.plugInClass;
}
role PlugIn {
method initWithHost (Host $h:) { ... }
}
role SupportsFeatureA {
# yes, this Role has a "class method" in it, which
# the consuming class will get as a "class method"
method supportsFeatureA (Class $c:) { bool::true }
}
role SupportsFeatureB {
method supportsFeatureB (Class $c:) { bool::true }
}
class AB {
does PlugIn;
does SupportsFeatureA;
does SupportsFeatureB;
}
role SupportsFeatureC {
method supportsFeatureC (Class $c:) { bool::true }
}
class ABC {
does AB;
does SupportsFeatureC;
}