On Wed, Apr 14, 2010 at 11:54 AM, David Cantrell <[email protected]> wrote: > > I have no idea whether it's also slower to access (some) fields of > Moosey objects than normal objects, but it's certainly something that > Moose sceptics will ask about, so I suggest benchmarking that too.
Good point. It also occurred to me to get some idea of memory footprint differences. > Depending on the lifetime of your objects, very slow instantiation might > not matter much - much like how it doesn't matter if a mod_perl-ised > Apache takes an extra coupla minutes to start. Quite so. I think in cases where I'm expecting to create a huge number of "objects" and am constrained by CPU time, I'd already be considering using simple hash refs instead of any kind of OO implementation. Moose would be for "everything else", which I think will be the majority of classes. >> * Roles are a mixed blessing and can encourage some very complex code, >> especially if inheritance is thrown into the mix > > I thought roles were meant to do away with inheritance. I think they provide a different, additional option beyond inheritance and object composition. But actually, what I was thinking of and didn't express properly was that it's possible to get a bit carried away with roles - e.g. putting every individual behaviour into its own role and creating several levels of role specialisation (roles being composed from other roles). The result being increased complexity and therefore increased maintenance costs, with little genuine benefit. Not exactly the fault of Moose and something that can be avoided by applying sensible policies and practices, but it seems to be a concern among my intended audience. > Is this for a new installation or application, or are you intending to > port an existing code-base to Moose? Most likely for new applications or libraries. Alex _______________________________________________ BristolBathPM mailing list [email protected] http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
