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