I wasn't thinking of those as types (and it wasn't meant as a final product, just an example of the way i was thinking about roles and does), I was thinking of them as roles since we are talking about does, and does talks about roles.

A given mode of dereferencing an object is merely an interface to that object. And as its an interface its a role. "Can i treat reference $x as a reference to an array?" could equally be thought of "can $x play the role of an array?".

I always thought of roles as abstract sets of characteristics and not the individual characteritics. So all regexs would be do the REGEX (or Regexp if you want to split hairs) role. That implies that it can be used as a regex just like things that do the ARRAY role are arrays. Dereferencing isn't a role, its a part of a role and it all then depends on how you actualy define the roles. If you as anything that reports to do ARRAY has to be able to be dereferenced as an array then you don't need @{} and ARRAY you just need ARRAY. Like i said before if you are asking about one specific method (derferncing or otherwise) wouldn't you wan to use 'can'? I think a generic "what do you claim to do?" and can is a "what have you actualy implemented" and i think joining the two concepts is more magical and confusing than needed.


___________
Eric Hodges

Roles are interfaces. Thats it. There is nothing more to them than that. Dereferencability of an object is simply an interface into that object. Therefore its a role the object can play.

So all regexs would be do the REGEX (or Regexp if you want to split hairs) role.

Its not splitting hairs. Whether a reference contains regexp magic is orthagonal to whether it is a member of any given class. Historically we marked all such references as being in class 'Regexp', however there is no requirement that this is true. A reblessed qr// unless the programmer does it deliberately is not isa('Regexp'). Therefore class is an inappropriate way to determine if an object can fulfil this role.

If you as anything that reports to do ARRAY has to be able to be dereferenced as an array then you don't need @{} and ARRAY you just need ARRAY.

Except that again this is not a necessary requirement, and indeed is one that is potentially dangerous. If I create an object that overloads array dereferencing then it can be used an array, regardless as to whether it has an isa relationship to the class 'ARRAY', in fact unblessed arrays themselves have NO isa relationship to 'ARRAY', this is an artifical artifact of how UNIVERSAL::isa() behaves. In addition /any/ object regardless of is type can be a member or subclass of 'ARRAY' without being dereferencable as an array, therefore 'ARRAY' is an inappropriate test to see if you can dereference an object as an array.

my $nasty = bless sub{},'ARRAY';
my $anon  = [];

if (UNIVERSAL::isa($anon,'ARRAY') == $nasty->isa('ARRAY')) 
{ print "isa says both are related to 'ARRRAY'" }
[download]

Now if you happened to actually define an 'ARRAY' class then perhaps this question would make sense, maybe there would be a reason to bless a subroutine into the class 'ARRAY', maybe you are using blessed closures as the implementation of a custom 'ARRAY' class. Whatever, the point is that being isa() 'ARRAY' isnt going to tell you with an certainty if the item actually can be dereferenced as an array. Or in other words does not tell you whether the array can play the role of an array reference.

---
$world=~s/war/peace/g