I tend to use a couple patterns each with their own rationale. However
I do not think there is any one convention for naming of roles, just
as with naming your classes, you need to use a name that is most
meaningful in the context.
So, for instance, I would call a role that serializes an object
"Serializable" as I think that it works better then HasSerialization,
DoesSerialize or any other combination/variation. The 'able' style I
think best fits when your role is giving a class some sort of
"trait" (in the sense of "character trait", not in the Moose sense of
the word) which implies a set of behaviors. The exception to this is
if a role is really only providing a single behavior, say the ability
to respond to a ->draw method, then sometimes I will call it something
like "CanDraw", which I think seems to have more specificity then
"Drawable". I also tend to use the "able" style for interface roles
(roles that provide no implementation and only require methods), but
that is just a throwback to Java.
I have also used the "With" prefix as well, when it made the most
sense. For instance, I am looking at a role right now for $work that
is called "WithImpactRanking", this adds additional optional
calculations to a class. It would not have made sense to call it
"HasImpactRanking" or "DoesImpactRanking" because the ranking is
optional and to me the "With" prefix implied the fact the ranking was
optional and in addition to the existing calculations already done by
the classes that consumed it. Of course this is subjective, to someone
else "HasAdditionalOptionalImpactRanking" might have made more sense.
Another favorite is if a role is providing access to something, say a
DBIx::Class schema object, I would then probably call it
"HasDBICSchema" as I feel that is pretty self describing. Of course
that is not a hard rule either as I see that I have a "WithCache" role
in my current $work project, which provides access to a cache object.
I think the "With" is more appropriate here since it not only provides
access to the cache object, but also some behavioral elements (methods
to fetch and store from cache).
I also have a few rules about where I put roles too, but as with the
naming conventions above, I make exceptions when it makes more sense
to do so. A good example of my two main approaches are in my Forest
module on CPAN (http://search.cpan.org/dist/Forest/).
You will see that I have a handful of interface roles
( Forest::Tree::Indexer, Forest::Tree::Loader,
Forest::Tree::Reader, Forest::Tree::Writer ) and then beneath them I
have the concrete implementations
( Forest::Tree::Indexer::SimpleUIDIndexer,
Forest::Tree::Reader::SimpleTextFile, etc).
I then also have a Forest::Tree::Roles::* namespace which has a set of
roles that are typically applied to Forest::Tree objects.
Of course, this is just how I roll, other people may have totally
different styles.
Hope this helps.
- Stevan
On Sep 1, 2009, at 3:35 PM, Jarrod Overson wrote:
If there's a better place to ask this, please point me in the right
direction. I've been a lurker and have searched the archive and docs
but haven't found all that much regarding naming conventions for moose
roles.
For this example, say i want to provide functionality to do Drawing.
I've seen roles named along the lines of Drawable, DoesDraw,
DoesDrawing, but no reference as to any set standard.
From an english standpoint, none of those sound all that great when
combined with the keyword 'with', either (with 'Drawable' or with
'DoesDrawing')
I've been working with the present continuous (progressive? - i'm not
a verb tense guru) form of a verb when writing a role with the
implementation being something that is capable of that verb, e.g.
package Drawing;
use Moose::Role
-----
package Custom::Drawable;
with 'Drawing';
----
package main;
my $drawable = new Custom::Drawable;
but am appealing for advice on any established conventions or
suggestions as to how to proceed. My approach breaks down with the
Moose::Manual example of a Car object implementing/consuming a
Breakable role which is part of what spurred this email because i'm
sure someone has put a lot more thought into it :-)
--
Jarrod
