I've considered uploading my module to the CPAN, but I've held off for a couple of reasons. First, I'm concerned that this might cause confusion with Perl 6 traits/roles (though this should be less of a concern if I document it well). The other reason is pretty straightforward: people don't know much about traits and if no one is likely to use the module, I don't see much sense in adding to the terminology glut. If you think that traits are something you would be interested in using, please let me know.

My design considerations:

• A primary class or trait implicitly promises some methods (these are the public methods in the class or trait).
• A primary trait may explicitly promise methods that are not directly available in its symbol table (due to inheritance or AUTOLOADing).
• A trait may expect certain methods.
• Method conflicts must be explicitly resolved.
• Traits may be composed from other traits.
• The resulting methods must be flattened into the primary class.
• Traits may not maintain state and should assume nothing about the internals of the objects that use them.
• This must be a easy to use as possible.

Since Perl 6 roles are not completely defined, I ignored them and used the original traits paper for guidance.

Here's my first pass (this code works, but I don't have a tarball uploaded anywhere), borrowing heavily from chromatic's Class::Roles example (because my examples were so politically incorrect that even I was a bit put off by them).

We have a person who wishes to have a LifeGuard trait, but only wants to dog paddle. Thus, even though a lifeguard can swim, we want the dog's &swim method. However, a dog might not swim without a doggie treat and the person doesn't have a &doggie_treat method, but it will AUTOLOAD one on demand.

package Person;
use Class::Trait 'LifeGuard';
use Class::Trait 'Dog' => { explicit => 'swim' };

Class::Trait->promise('doggie_treat');
Class::Trait->assemble; # this flattens the traits into this class

sub AUTOLOAD {
  # we'll make &doggie_treat, if needed
}

1;
[download]

The traits look like this:

package Trait::LifeGuard;

sub swim {
  return Trait::LifeGuard::_swim();
}

sub save_drowning_swimmer {
  my (undef, $swimmer) = @_;
  # save the swimmer
}

1;

package Trait::Dog;

Class::Trait->expects('doggie_treat');

sub swim {
  # $class might actually be an instance, but we should assume
  # nothing about the internals of the object
  my ($class, $target) = @_;
  Trait::Dog::_eat($class->doggie_treat);
  # swim to $target
}

sub _eat {
  # this must be called via a fully qualified name because private
  # methods are not flattened into the primary class
}

1;
[download]

The way this works is simple (in theory, not in code). As traits are added, promises made and expectations listed, I build a composite interface (similar to a Java interface). When Class::Trait->assemble (should I call that 'flatten'?) is called, the interface is validated and conflicts are resolved. Unresolved conflicts are fatal, as are unmet expectations.

Questions:

• Have you ever used traits in any language?
• Would you use a traits implementation in Perl?
• How would you improve the interface above?