Larry Wall wrote: > What I'm currently thinking about is a "does" predicate that tells you > if an object/class does a particular role completely. If you pull > part of a role into a class, it returns false, because it doesn't do > the complete role. However, if you use "like" instead, it returns a > number between 0 and 1 telling you what fraction of the role's methods > it uses. So you can ask if your object is more like a Dog or a Tree. > > Unless someone comes up with a better idea, of course. Obviously > .does() is redundant with .like() == 1. But it seems like a useful > redundancy.
I'd rather they not be redundant. Instead, C<does> would check to see if the role in question is ever directly referenced anywhere in the class definition (or in any of its parent class' definitions), whereas C<like> would check to see how many of the methods and/or attributes supplied and/or demanded by the role are available to the class. Thus, a class that includes a C<bark> method but no C<Dog> role will return a not purely false value for the C<like> predicate, but would return false for the C<does> predicate. This would tell you that the class can bark, but not neccessarily like a Dog. Whereas if it answers true to C<does>, you know that when it barks, it will likely do so in the manner that a Dog does. Furthermore, I have my doubts about how useful a zero-to-one number would be as a return value for C<like>. Personally, I'd rather get a junction of C<can> and C<has> predicate calls, which I could then query to find out exactly how the class is C<like> the role in question, and how it differs. That is, C<$x like $y> := C<any($x »can« @methods($y)) or any($x »has« @attributes($y))> or C<all($x »can« @methods($y)) and all($x »has« @attributes($y))> or maybe just C<$x »can« @methods($y), $x »has« @attributes($y)> ===== Jonathan "Dataweaver" Lang __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html
