They don't play nicely with Data::Dumper or StorableYeah, but is that a bad thing? 'Data::Dumper' and 'Storable' only work by making assumptions on how objects are implemented - they assume the entire state can be captured by capturing the content of the referent. Which, in many OO circles, is seen as very bad programming. Not playing nice with someone who isn't playing nice isn't necessarely bad IMO.
They can have memory leaks (even Class::Std can under pathological circumstances)What circumstances are those?
They are about 10x slower than hash- or array-based objects under average useDo you have a benchmark? I'm not at all interested in the numbers - what I'd like to see is what you classify as "average use".
Extending the class on the fly is unintuitiveReally? How is extending the class when using inside-out objects any different from non inside-out objects? Or do you mean "I can't get at the data"? That seems to be the point Damian is making in his book, isn't?
Subclassing can still have bad situationsWhat do you mean by that? What is a "bad situation"?
In reply to Re^3: Help understanding object constructors (by Perl Best Practices book)
by Perl Mouse
in thread Help understanding object constructors
by nisha
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |