On 07/15/2010 01:35 PM, Jesse Luehrs wrote:
On Thu, Jul 15, 2010 at 01:15:53PM -0400, Sir Robert Burbridge wrote:
On 07/14/2010 11:27 PM, Jesse Luehrs wrote:
On Thu, Jul 15, 2010 at 02:31:26PM +1200, Sam Vilain wrote:
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 disagree here - this would imply that anything written as a role could
go under MooseX (since roles don't exist outside of Moose), and that's
pretty wrong in my opinion. I pretty much agree with Dave here (and I
think that a reasonable low bar (necessary, but not sufficient) is that
it explicitly touches a metaclass somewhere, although I haven't put very
much thought into whether that's reasonable or not).
-doy
I would argue that "MooseX" is intended to mean "Moose Extensions,"
which should be interpreted "Modules that extend the functionality of
Moose."
I can't tell if you're agreeing or disagreeing with me here. Any
arbitrary role doesn't necessarily extend the functionality of Moose,
and I'd argue that if you're not touching metaclasses, you aren't
extending the functionality of Moose (with the possible exception of
type stuff, I forgot about that yesterday).
-doy
I was agreeing with the more restricted interpretation of MooseX.
MooseX:: is appropriate for modules that extend the functionality
provided by Moose /as such/. That is, "Moose provides metaprogramming
capabilities." The MooseX name implies modules that extend moose's
metaprogramming provision. Moose roles (such as "...::PizzaMaker" may
enhance your module's pizza-making abilities, but it doesn't enhance
your module's OOP capabilities (which is what Moose is for).
If you write a PizzaMaker module that let's you make pizza with crust
and toppings, PizzaMakerX::Crust::CheezyCrust may make sense, but
probably not PizzaMakerX::Come::To::My::Store::We::Sell::PizzaMaker::Pizzas.
The same for DBIx, or whatever other. DBIx::My::Module::Uses::DBIx is
silly. But DBIx::Extended::DB::Functionality isn't (except for the name).
=)
-sir
