[sf-perl] Mouse, again?

[Joseph Brenner]

Quinn Weaver <quinn at pgexperts.com> wrote:

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

Obviously, we need an ORMI that provides a consistent interface to any
ORM you're interested in using.


On Mon, Mar 5, 2012 at 4:25 PM, Quinn Weaver <quinn at pgexperts.com> wrote:
> 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)
>
>
>
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>