[sf-perl] Mouse, again?

Quinn Weaver quinn at pgexperts.com
Mon Mar 5 16:25:32 PST 2012


On Mar 5, 2012, at 2:47 PM, Fred Moyer wrote:

> 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.

But… RDBO and DBIC have totally different APIs. How would Any::ORM operate without breaking your code?

> 
> For example, I wrote Any::URI::Escape, and it tries to load
> URI::Escape::XS, and falls back to URI::Escape (pure Perl).
> 
> http://cpansearch.perl.org/src/PHRED/Any-URI-Escape-0.01/lib/Any/URI/Escape.pm
> 
> Any::Moose looks like it loads Moose, then Mouse if Moose can't be found:
> 
> http://cpansearch.perl.org/src/SARTAK/Any-Moose-0.18/lib/Any/Moose.pm
> 
> 
> 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
>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


--
Quinn Weaver
PostgreSQL Experts, Inc.
http://pgexperts.com/
1-888-743-9778 (my extension: 510)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120305/0e09077b/attachment.html>


More information about the SanFrancisco-pm mailing list