[sf-perl] Mouse, again?
fred at redhotpenguin.com
Mon Mar 5 13:08:33 PST 2012
On Thu, Mar 1, 2012 at 5:08 PM, Joseph Brenner <doomvox at gmail.com> wrote:
> By the way: I've thought about it, and concluded that for my purposes
> I have no interest in using the wrapper module Any::Moose: by design,
> it's a way of using Mouse without committing to it permanently, if it
> sees Moose installed it will use that instead. That strikes me as a
> potentially nasty action-at-a-distance performance bomb I would rather
> not inflict on whoever needs to maintain this code.
Personally, I'm becoming a big fan of the Any::* modules, especially
Any::Moose. Any::* provides loose coupling for your application. If
you've worked on an application that tries to use the esoteric
features of a module such as Moose (this is an example in name only),
and the developer decides to change those 20% features which are the
least used, you have a maintenance problem.
Plus, while it may take a developer 2 minutes to install Moose on a
solid state laptop, it may take sysadmins or release engineers much
longer since they are using shared resources. Or production hardware
which has test failures in dependent modules, such as 64 bit
production environments. Two minutes for a developer can turn into
two weeks for a production deployment in larger organizations.
I've seriously considered writing Any::ORM to frontend DBIx::Class,
Rose::Object, Class::DBI::Sweet (don't use that module for new
projects by the way, maintainer here speaking), or any of the other
ORMs out there. Some of the faster moving ORMs are not backwards
compatible across previous versions, or they have new features which
break existing features, or they have intermittently socially unstable
development team issues.
Any::* is somewhat of an insurance policy against these issues I've mentioned.
More information about the SanFrancisco-pm