[sf-perl] Mouse, again?
fred at redhotpenguin.com
Mon Mar 5 14:47:45 PST 2012
On Mon, Mar 5, 2012 at 1:18 PM, Quinn Weaver <quinn at pgexperts.com> wrote:
> 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?
I believe the Any:: modules just load modules preferentially in order
they are found.
For example, I wrote Any::URI::Escape, and it tries to load
URI::Escape::XS, and falls back to URI::Escape (pure Perl).
Any::Moose looks like it loads Moose, then Mouse if Moose can't be found:
So perhaps my Any::ORM theoretical project would be better named Whatever::ORM
I see the 'insurance' benefits for ANY:: mostly being
development/production platform heterogeneous compatibility.
> 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.
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
More information about the SanFrancisco-pm