On 11/4/05, Austin Frank <[EMAIL PROTECTED]> wrote:
> Hello!
>
> If roles are interfaces, do we want any class that provides an interface
> consistent with a role to implicitly do the role? That is, if a class
> fulfills all of the interface requirements of a role without actually
> saying it does the role, does it do the role anyway?
>
> role Documented {
> has $.documentation;
> }
>
> class Foo does Documented { ... }
>
> # I don't know why Bar isn't declared as doing Documented
> # but it meets all the requirements of doing Documented...
> class Bar {
> has $.documentation;
> }
>
> my $baz = Foo.new( $documentation => "q to quit" );
> my $qux = Bar.new( $documentation => "enter to continue" );
>
> sub show_docs ( $obj.does( Documented ) ) { # or $obj ~~ Documented
> say $obj.documentation;
> }
>
> show_docs( $baz ); # "q to quit"
> show_docs( $qux ); # "enter to continue" -or-
> # error because Bar doesn't explicitly do
> # Documented?
>
>
> I guess we don't really need implicit doing of roles to get both of
> those objects to print their documentation, as we could have something like
>
> sub show_docs ( $obj ) {
> if ( defined $obj.documentation ) {
> say $obj.documentation;
> }
> else {
> die "Should have included a documentation string"
> }
> }
>
>
> Should roles that are implicitly done pass tests like .does and ~~ ?
> What are the reasons that they should or shouldn't?
I say no. It goes back to does a role provide a list of function names
with possible default implementations or does it provide a behavior
that is supported by a set of related functions that one can override,
if desired. What you're proposing assumes that roles are nothing more
than jazzed up Java interfaces. I would hate to see that happen. So, I
say that it should be the latter.
Rob
