Clear questions and runnable code
get the best and fastest answer
Re^5: On collaboration between projectsby stvn (Monsignor)
|on Feb 20, 2009 at 16:29 UTC ( #745394=note: print w/replies, xml )||Need Help??|
Well, here's another non-Moose data point. We don't use it and probably never will.
Fair enough, it is not for everyone or every situation. In fact, I have found the people who are most resistant/hesitant to using Moose are the ones who have a clean set of OO "best practices" which work perfectly fine for them already. For them Moose only seems to provide extra baggage and not much more.
That said, I think this perception is feed by the fact that Moose (to them) seems only to be a "sugar" layer over normal Perl OOP. This is very much not true. Moose is built on Class::MOP, which is a formal object system for Perl which provides a pretty robust meta-programming environment. Every bit of "weight" in Moose is there for good reason and in fact the "sugar" end is quite light. Several former non-believers were converted after they took a closer look and realized that Moose is not just about the sugar. But as I said above, it is not for everyone, however I do encourage you to look a little deeper before you dismiss it (assuming you haven't already, in which case this statement is less for you the poster of this post and more for you the reader of this post).
What I like about the current Perl approach to objects is that it is thin.
Yes, but that thin-ness means you have to do a whole lot of tedious and repetitive code to just get some of the basic features that any other OO language would provide. I love the core Perl OO system too, but every time I used another language and then returned to Perl, I found myself wanting more.
It provides a layer of insulation to consumers of your objects without getting in the way of finding a best implementation internally to the object and without adding a lot of overhead.
Ah ha, see Moose does that for you (the programmer) as well. The meta-object protocol (MOP) provides a the means to change the internal representation of the object without having to re-write the entire object system. See MooseX::Object::GlobRef and MooseX::InsideOut for examples of that.
Yes, I know you will say "but it adds a lot of overhead", but this is really only true of compile time, not at runtime. Typically Moose accessors will benchmark as fast as hand-coded Perl accessors, and if you make the class immutable we will inline your constructor and destructors as well.
... but for systems that are that large and complex (loads of subclasses, co-varying types, etc), we use Java (gasp!), since the strict typing and compiler do a great job of inferring the correctness of code built around complex type systems.
Careful, Java's type system is not really that bullet proof, the simple fact you have dynamic casting means there is a giant gaping hole in the foundation of the type system. And javac very much does not "infer the correctness of code" it only verifies that you have not broken any of it's rules. If you really want to verify correctness you need something more like Haskell or Ada, but even those languages have their weaknesses.
IMHO, any system complicated enough to justify the complexity of Moose needs something more robust and inferential than Moose.
I disagree here because I think that while Moose itself might be a complex system, Moose code itself tends to be simpler then traditional Perl OOP. Including the complexity of Moose itself would be equivalent to saying "I cant justify using Java because javac is too complex a program".
Again, I must disagree with your implication that Java is "inferential" in any way. Java infers nothing, you explicitly tell it all about your types and classes and it just verifies that you are being consistent with your usage, any inference of "correctness" after that is your own, not Javas.
In Section Meditations