[sf-perl] Mouse, again?
doom at kzsu.stanford.edu
Mon Mar 5 15:09:44 PST 2012
Fred Moyer <fred at redhotpenguin.com> wrote:
> Any::Moose looks like it loads Moose, then Mouse if Moose can't be found
Right, exactly. So if you're writing code intended to be portable to
different environments, where you're not sure if Moose or Mouse will
be installed, using Any::Moose could be a good idea.
The scenario that bothers me is:
(a) assume that Moose has some large performance penalty (this may
have been exaggerated, but there has to be some or Mouse doesn't make
any sense at all).
(b) I write a bunch of code that uses Mouse.
(c) later, Moose gets installed. Note: the person doing this might
not have thought about it very much, it might just be a dependency of
something else they're experimenting with.
(d) the code that I've written develops some odd performance problems,
despite the fact that nothing has apparently changed with it.
On Mon, Mar 5, 2012 at 2:47 PM, Fred Moyer <fred at redhotpenguin.com> 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.
> 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
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
More information about the SanFrancisco-pm