<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 5, 2012, at 2:47 PM, Fred Moyer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Mon, Mar 5, 2012 at 1:18 PM, Quinn Weaver <<a href="mailto:quinn@pgexperts.com">quinn@pgexperts.com</a>> wrote:<br><blockquote type="cite">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?<br></blockquote><br>I believe the Any:: modules just load modules preferentially in order<br>they are found.<br></div></blockquote><div><br></div><div>But… RDBO and DBIC have totally different APIs. How would Any::ORM operate without breaking your code?</div><br><blockquote type="cite"><div><br>For example, I wrote Any::URI::Escape, and it tries to load<br>URI::Escape::XS, and falls back to URI::Escape (pure Perl).<br><br><a href="http://cpansearch.perl.org/src/PHRED/Any-URI-Escape-0.01/lib/Any/URI/Escape.pm">http://cpansearch.perl.org/src/PHRED/Any-URI-Escape-0.01/lib/Any/URI/Escape.pm</a><br><br>Any::Moose looks like it loads Moose, then Mouse if Moose can't be found:<br><br>http://cpansearch.perl.org/src/SARTAK/Any-Moose-0.18/lib/Any/Moose.pm<br><br><br>So perhaps my Any::ORM theoretical project would be better named Whatever::ORM<br><br>I see the 'insurance' benefits for ANY:: mostly being<br>development/production platform heterogeneous compatibility.<br><br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Mar 5, 2012, at 1:08 PM, Fred Moyer <fred@redhotpenguin.com> wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On Thu, Mar 1, 2012 at 5:08 PM, Joseph Brenner <doomvox@gmail.com> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">By the way: I've thought about it, and concluded that for my purposes<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I have no interest in using the wrapper module Any::Moose: by design,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">it's a way of using Mouse without committing to it permanently, if it<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">sees Moose installed it will use that instead.  That strikes me as a<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">potentially nasty action-at-a-distance performance bomb I would rather<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">not inflict on whoever needs to maintain this code.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Personally, I'm becoming a big fan of the Any::* modules, especially<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Any::Moose.  Any::* provides loose coupling for your application.  If<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">you've worked on an application that tries to use the esoteric<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">features of a module such as Moose (this is an example in name only),<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and the developer decides to change those 20% features which are the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">least used, you have a maintenance problem.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Plus, while it may take a developer 2 minutes to install Moose on a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">solid state laptop, it may take sysadmins or release engineers much<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">longer since they are using shared resources.  Or production hardware<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">which has test failures in dependent modules, such as 64 bit<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">production environments.  Two minutes for a developer can turn into<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">two weeks for a production deployment in larger organizations.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I've seriously considered writing Any::ORM to frontend DBIx::Class,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Rose::Object, Class::DBI::Sweet (don't use that module for new<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">projects by the way, maintainer here speaking), or any of the other<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ORMs out there.  Some of the faster moving ORMs are not backwards<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">compatible across previous versions, or they have new features which<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">break existing features, or they have intermittently socially unstable<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">development team issues.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Any::* is somewhat of an insurance policy against these issues I've mentioned.<br></blockquote></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">SanFrancisco-pm mailing list<br></blockquote><blockquote type="cite">SanFrancisco-pm@pm.org<br></blockquote><blockquote type="cite">http://mail.pm.org/mailman/listinfo/sanfrancisco-pm<br></blockquote></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Bitstream Vera Sans Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><div><br class="Apple-interchange-newline">--</div><div>Quinn Weaver</div><div>PostgreSQL Experts, Inc.</div><div><a href="http://pgexperts.com/">http://pgexperts.com/</a></div><div>1-888-743-9778 (my extension: 510)</div></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>