Sam,
On Jul 14, 2010, at 10:31 PM, Sam Vilain wrote:
On Tue, 2010-07-13 at 16:03 -0700, Darren Duncan wrote:
Perhaps someone has some thoughts on where the line should be
drawn; for
the above I would have thought it was a Moose extension.
Maybe a general criteria is that MooseX:: could be for modules whose
functionality might have reasonably been built-in to Moose itself,
but that
weren't in the interest of keeping Moose from bloating or because the
functionality is experimental etc.
The problem I see with that is that this is a very vague call to make.
What are valid reasons that something might become built-in to Moose?
What are invalid reasons?
Yeah, the line is a little blurry, and likely will always be so
(unfortunately).
In contrast, something that depends on Moose but wouldn't
reasonably be built-in
to Moose under normal circumstances would be a candidate for not
being a
MooseX::. For example, the functionality of KiokuDB is best not in
a Moose:: or
MooseX:: namespace, and indeed it isn't.
Non-functional names I think are not a good argument for anything
other
than the author decided to give it a cute name. There's also
MooseX::Storage, for example.
MooseX::Storage should likely be named something different.
I'm currently considering whether or not to rename PRANG to the far
more
suitable name MooseX::XML (as I mentioned on IRC, once the API can be
compatible with XML::Toolkit) - I think this is appropriate because
its
API is heavily based around the Moose metamodel. It is therefore, a
moose extension - it lets you add more functionality to your Moose
classes. But XML support would never belong in Moose itself.
I think PRANG should stay PRANG.
Even though it might be tightly coupled to Moose, it doesn't mean it
is appropriate as a MooseX::. There are a lot of modules that are
deeply tied to Moose (Bread::Board for example), but that should not
be MooseX::.
I would suggest that as a better distinction - if the *API* is
fundamentally tied to Moose, then delivering to a MooseX:: namespace
is
much more acceptable. If the API is not Moose-specific, then it
should
not be.
I am not sure if this is a good distinction either, I think if it
truly extends the functionality in Moose (adds attribute metaclass/
metatrait feature, changes the behavior of role composition, etc),
then it should be a MooseX::.
I'd appreciate wider commentary on this point, especially since it is
the topic of an upcoming YAPC talk and this comment on the list has me
wondering wtf.
Like I said, it is a fuzzy topic. And it likely always will be since
you really cant control what people upload. The core Moose team does
keep an eye on the namespace and occasionally we do ask people to
change the name of a MooseX:: module if it is really not appropriate.
Honestly, the best policy would likely be to simply ask the list or
IRC and get a public discussion going about it.
- Stevan
