Leon Timmermans wrote:
> I assumed a new role makes a new interface. In other words, that a
> type that happens to do Pollable, Mappable, Statable and Ownable
> wouldn't automatically do File in that case. If I was wrong my abuse
> of subset wouldn't be necessary. Otherwise, maybe there should be a
> clean way to do that.
Hmm... true enough.
There was another contributer here who proposed an "is like" modifier
for type matching - I believe that he used £ for the purpose, in that
'File' would mean 'anything that does File', while '£ File' would mean
'anything that can be used in the same sort of ways as File'. That
is, perl 6 uses nominative typing by default, while '£' would cause it
to use structural typing (i.e., "duck-typing") instead.
FWIW, I'd be inclined to have anonymous roles use duck-typing by
default - that is, "$Foo.does role {does Pollable; does Mappable; does
Statable; does Ownable}" would be roughly equivalent to "$Foo.does £
role {does Pollable; does Mappable; does Statable; does Ownable}" -
the theory being that there's no way that a role that you generate on
the fly for testing purposes will ever match any of the roles composed
into a class through nominative typing; so the only way for it to be
at all useful is if it uses structural typing.
(I say "roughly equivalent" because I can see cause for defining "£
Foo" such that it only concerns itself with whether or not the class
being tested has all of the methods that Foo has, whereas the
anonymous "role {does Foo}" would match any role that does Foo. As
such, you could say things like:
role {does Foo; does £ Bar; has $baz}
to test for an object that .does Foo, has all of the methods of Bar,
and has an accessor method for $baz.
--
Jonathan "Dataweaver" Lang
