[sf-perl] Mouse, again?

Quinn Weaver quinn at pgexperts.com
Mon Mar 5 13:18:18 PST 2012

I haven't used a lot of Any:: modules, except for JSON (where the API is tiny). Is the usual pattern for the Any:: module to implement all of the least common denominator of the underlying modules, or a subset of the LCD, or something else?

Quinn Weaver
PostgreSQL Experts, Inc.  http://pgexperts.com/
1-888-743-9778 (my extension: 510)
Sent from my phone; please pardon my brevity.

On Mar 5, 2012, at 1:08 PM, Fred Moyer <fred at redhotpenguin.com> wrote:

> 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 mailing list