On Sun, Jun 9, 2013 at 10:31 PM, Darren Duncan <dar...@darrenduncan.net> wrote: > I second Reverend Chip's comment. Too much what its implemented with rather > than what it does among module names. -- Darren Duncan > > > On 2013.06.09 8:26 PM, Reverend Chip wrote: >> >> Might it be better simply to name the class what it does, and have its >> moosey-ness go unnamed? Imagine if we started naming things "OO::" when >> we started using classes, and never stopped.
My only argument against is that sometimes things only make sense in the context of Moose, for example the equals role I mentioned in another thread would be a Moose Role. It's not a Moose Extension, but neither does it make sense outside of the context of Moose. In fact I can think of more than one Role where it would make sense to give it some kind of a Moose based namespace. Another example was a MooseX::NonMoose subclass of DateTime that I did once, because I needed to give DateTime a MOP because another module confessed to me that it couldn't live with itself if I used MOPless modules. Of course I also agree with things having their own namespace if they can stand alone and be useful irregardless of Moose. CHI, Bread::Board, Catalyst, Business::CyberSource, Business::PaperlessTrans (the last 2 are mine) all come to mind. Of course I'd note that Bread::Board and Catalyst say nothing about what they do, neither does Moose for that matter, but I think that this kind of naming only works well for larger things, not single pm roles. Basically this is just a suggestion for things that don't make sense in a context outside of Moose, of course like MooseX people will probably abuse it. At least it'd be giving them a place to go, instead of just saying, you have to leave but you can't stay here (in a place you can't enforce that). -- Caleb Cushing http://xenoterracide.com
