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? > 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. 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 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'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. Sam
