Home > Programming > Roles & Duck Typing; Apples & Oranges

Roles & Duck Typing; Apples & Oranges

chromatic’s most recent post on roles at his Modern Perl Books blog compares Roles to duck typing. (If you haven’t read his ongoing series of posts on roles yet, it’s a great way to get up to speed with some of the theory behind roles, in reasonably easy-to-understand terms). Given that duck typing is a favoured technique of Python and Ruby developers, it’s not too surprising that his post got a response, which seems to be fairly skeptical of roles.

While I think chromatic’s points are valid, reading just that post about roles could lead one to get the completely wrong end of the stick. For instance, one blogger replied with a post saying:

Perl roles will force you to specify all of your roles explicitly, and require that appropriate object class code indicate a role behavior where necessary. This is “bad” complexity imho, since it involves a lot of boilerplate and class code markup. On the other hand, duck typing will force you to be very careful and specific with how you define a typedef, and occasionally force you to change how fields are named.

I guess the first thing to say is that roles in no way preclude duck typing. There’s nothing stopping you doing:

$object_with_role->can('some_method');

Roles don’t suddenly make Perl statically typed (duck typing is really just polymorphism without types). You don’t lose any flexibility you have with duck typing. But of course, you can also say:

$object_with_role->does('SomeRole');

This introspection is deeper than ‘can’. It’s asserting that this object has several methods and attributes that we know about, rather than just one. So this could potentially lead to cleaner code on the caller’s side, as we know a lot more about the object with a single introspection call, rather than being forced to call ‘can’ multiple times.

However, all this (to me) is a fairly minor benefit of roles. The more important aspects are around class composition. Duck typing in and of itself doesn’t really solve the problem of code re-use. It just says you don’t have to have a type hierarchy in order to use polymorphism. But if you want to re-use code, and you don’t like type hierarchies (i.e. inheritance), your only option is to either step outside the realm of OO (not necessarily a bad thing, but outside the scope of this discussion) or compose your classes in another way, such as delegation, mixins, or traits/roles.

To really understand what chromatic’s point was, you need to read his series of posts. He’s not claiming roles are a superior drop in replacement for duck typing. He’s saying there are problems with duck typing in some cases, and roles can help with that. But he also has an earlier post on how roles can help with some of the problems of inheritance, and has promised a future one on Java interfaces.

The point is, roles have advantages over all these techniques in some (not all) circumstances. They’re a relatively new addition to the OO toolbox. They seem to address a lot of issues that some of the more established techniques have, and appear to be more than a fad, as they have a fairly solid theoretical underpinning. (I won’t go into the details of roles and class composition now; chromatic’s posts are likely to be far better than mine, so I’d recommend you read those. Although I did discuss this a bit in my previous post on roles). But that doesn’t mean all the other techniques are necessarily obsolete and worthless. After all, there’s more than one way to do it.

So to those who have looked at roles and believe they’re an inferior alternative to duck typing, I’d suggest you do some more reading, because I don’t think you’ve grasped what roles actually give you. The real advantages are in the realm of class composition, not type checking.

About these ads
Categories: Programming Tags: , ,
  1. May 7, 2009 at 7:10 pm | #1

    Infact (despite some argument) Moose supports both Roles *and* duck typing explicitly in it’s type system. That is to say that there’s a duck_type keyword you can optionally export that will perform a simple ->can() test on a value for a list of methods. This is relatively recent, but was introduced exactly because I didn’t want to have to create an interface Role, and then Moose wrappers for classes I downloaded off CPAN just so I could have some type checking on the interface.

  1. May 8, 2009 at 4:59 am | #1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: