On 28/07/10 06:08, Evan Carroll wrote:
with ::Role:: being in the middle of the name, rather than at the
beginning or at the end.
Again, I'm not sure this answers anything at all. Would it make more
sense to put ::Moose:: in the package name of classes that used Moose
internally? If no, why? What is your opinion if someone creates a
WiX3::XML::Tag that is non-Role Moose class. I'm just not sure why
people want this. If people want to shop for roles that they can use
to enhance their Moose classes, why not just add the functionality
into search.cpan, or Meta.yml. ... What if the Role is some how
fundamentally more often useful as a Trait? Should it be published as
WiX3::XML::Trait::Tag.
it just seems like we're using package names to store random crap
about the module that has nothing to do with the *name* of the module
and is much better inferred and indexed on the content of the module.
Being a Trait has very little to do with the *function* of the module.
A Trait isn't all that far from any other module that uses SubExporter
for method-install. Should we give those a separate namespace?
I think having Role:: in the package name is important, and it does
convey information about the function of a module. A role has a use case
that is substantially different from a class - you do not instantiate
it, you compose it. For this reason alone, I personally enjoy the
separation of instantiable objects - my classes - and roles. This is not
dissimilar to the C++ practice (or perhaps it's Java) of prefixing all
interfaces with an "I"
And yes, if a role is more useful on a per-instance basis as a trait,
then I do indeed put them in a ::Trait namespace. I find this to be
particularly self-documenting then - it's clear that this is neither a
class, nor a role that you should apply to a class, but a trait that
should be applied to isolated instances of a class.
So no, I don't think we're storing random crap at all in the package
name here. You might consider it crap, but it's most certainly not
random at all - so please don't start getting overly subjective here. In
regards to SubExporter doing method installs, yes I would probably also
put that in a separate namespace - I believe this is what the Mixin
namespace is for.
--
Oliver Charles / aCiD2
