Before I embark on Mango with reckless abandon, I was thinking about possibly using Moose for it's non-Cat internals.
Who's using Moose out there? How's it going? Pros, cons, other? :-)
What's you're reason for using it, beyond that it looks like a cool idea (and it does, although I'm not using it myself
It seems to me that Moose is a fast moving target and is changing rapidly. Will using it save you time and, more importantly, will it help or hinder the promotion of Catalyst/Handel in the wider community (one of the aims of the Mango project) ?
My cautious side would say that it's adding another layer of learning & potential dependency problems and should therefore be avoided for this particular project.
Simon
Re:Does it add value to the example ?
jk2addict on 2006-08-25T16:49:51
Mostly for the before/after/around hooks to allow people to get at events. Sure, it can be done in other ways, but Moose seems the cleanest.Re: Speed of Moose
Stevan on 2006-08-25T20:04:19
It seems to me that Moose is a fast moving target and is changing rapidly.Actually, Moose's internals are changing/improving rapidly, but it's outer sugar coating is pretty stable, and will not change without sufficient warnings if at all.
Will using it save you time and,... ? One of the more common reactions I get from people using Moose is how much (developer) time it saves them. I know for myself, it has made refactoring a large unweildy codebase a lot easier. In fact with that, most of my time has been spent removing code that Moose can handle is much fewer lines.
My cautious side would say that it's adding another layer of learning & potential dependency problems and should therefore be avoided for this particular project.Well, I know many of the Catalyst folks have been looking at using Moose, so it the "another dependency" issue is moot if/when that happens. As for the learning curve, Moose (IMHO) should actually make it easier, especially for a non-perl audience who are used to a proper object system.
- Stevan
Well, my opinion obviously is heaily biased, however I am actually using Moose in real $work, so I figured I am still qualified to comment
ConsWell Moose takes care of a lot of redundant and tedious code (constructors, accessors, etc), basically making easy things even easier and much less tedious. Sure you could use the more standard solution of Class::Accessor, but that forces you to put Class::Accessor in your @ISA, and it does not initialize attributes for superclasses automatically like Moose will. Anyone who has programmed in another OO language should appreciate things like this Just Working.
Moose tends to also make code more readable. Once you learn the basic "syntax" (which is heavily based on Perl 6), most people find Moose very easy to read and very descriptive since Moose allows you to put in lots meta-information in your attributes. Not only does this give you basic type checking, it makes you intentions for the attribute much clearer, which makes it easier for someone 6 months down the road to see whats going on.
And lastly, Moose (more specifically Class::MOP) makes class introspection very clean (no more symbol table hackery needed). This is usually not needed for 90% of code out there, but when programming "frameworks" it can come in really handy.
In short, Moose can help save developer time (see item #1), help increase mantainability (see item #2) and makes tricky thing look less like line-noise (see item #3).
It would be unfair if I didn'd list some of the cons of Moose.
To start with, speed is an issue. Currently Moose is much slower than lovingly hand coded Perl. We are working on this and have made some signifigant strides towards speeding things up (and there is still room to speed up more), but it is not there yet. Currently we are optimizing for "theoretical correctness" which we hope will make it easier to optimize for speed later (see Haskell for more info
:)). Next would be memory consumption. Moose creates a number of meta-objects to power many of it's features, however they are per-class and not per-instance so this is probably not that big of a deal unless you have hundreds of classes in your system.
And lastly, startup time. Because Moose does much of it's calculations and such during compile time, it will increase startup time. This will be even more true when we add the optimizations to benefit the runtime. It is possible that we can overcome this using Module::Compile and
.pmc files to cache the compiled results, but that is still a ways off.
Hope this helps.
- Stevan
