Apocalypse 12 has the following to say about roles and trust
(http://www.perl.com/pub/a/2004/04/16/a12.html?page=10)
It's not clear whether roles should be allowed to grant
trust. In the absence of evidence to the contrary, I'm
inclined to say not.
In Perl 5, I recently found myself in the annoying position of having a
method which could accept scalar, array, or hash references. My
primary code looked similar to this (simplified for clarity):
sub _attributes {
my ($self, $attrs) = @_;
return $$attrs if UNIVERSAL::isa( $attrs, 'SCALAR' );
my @attributes = UNIVERSAL::isa( $attrs, 'HASH' )
? %$attrs : @$attrs;
return unless @attributes;
# more code here
}
This was a private method, but $attrs is an argument that is passed in
by the person using my class. It would be nice if I could just assign
an "attributes" role to the SCALAR, ARRAY, and HASH classes and say
that only my class could see the method(s) it provides. Thus, my
caller would be blissfully unaware that I am doing this:
$attrs->attributes; # even if it's an array reference
This would get rid of all of the bad UNIVERSAL::isa type of code and
allow Perl to handle the dispatching instead of the programmer. While
most probably don't do stuff like this, I think it's a great example of
why role should be allowed to specify trust. I've been using
"role-like" behavior quite a bit in a large test suite I'm working on
and it would be nice to be able to do stuff like this.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
