Jonathan Worthington wrote:
But names of types need to also be specifiable as keys for full
flexibility? Since they may be in any namespace, not just the current one.
Fair enough. But I'll be very clear that using a key to specify a type
is *not* the same thing as using a key to specify a namespace. We only
use keys to provide a language-agnostic way of combining pieces of the
type name. And it's only a convention that the default type name of a
class happens to correspond to the namespace hierarchy for the class.
The type for a class in the namespace [ 'My'; 'Lengthy'; 'Hierarchy';
'Thing' ] may be just Thing.
+When declaring a class, you can optionally supply an array of method
names that
+will be supplied by the composed class because of a conflict in the
roles.
Should that read "...supplied by the class because...."?
Because it sounds like "a class" and "the composed class" are different
things? I'll add "composed" earlier so it's clear that we're talking
about the same thing in both cases.
"When declaring a composed class, you can optionally supply an array of
method names that will be supplied by the class because of a conflict in
its roles."
This
+is done using the named parameter C<resolve>. This feature supports
composition
+conflict resolution in languages such as Perl 6.
You can already do this, by passing the same list to "exclude" for each
role. That doesn't seem to great a hardship to me - I just wanted to
make sure it was clear that this feature was just sugar, not adding
anything new? Note that to implement this the class has the keep the
resolve list around too, making classes a little bigger in memory (not
much I know, it's just an "is it worth it" question).
The difference is that marking them on the class applies to all roles,
not just a particular individual role. It also makes it possible to
check whether the class actually implemented the specified method, and
gives you introspective capabilities into method composition conflicts
resolved by the class. In general, C<resolve> is the preferred strategy
for conflict resolution, and we only provide the per-role C<exclude> as
a tool for languages that allow individual method exclusion. (I nearly
removed the C<exclude> feature entirely, but decided it was useful
outside of conflict resolution.)
Guess the talk of offsets need to go away, that's ye olde object model.
Deleted. (Consistency pass coming up after I finish responding to
questions.)
Allison
