I think an important criteria for an object module is the support channels. If it is not a simple module, then we need to be assured that we can get rapid help from the author or user community.
Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality.
| [reply] |
| [reply] |
Class::MethodMaker and Class::MakeMethods are indeed excellent modules.
I'm congradulating the authors, and especially, simonm and friends for the excellent documentation provided for the module. But let's set one thing straight. MethodMaker seems more compact than MakeMethods.
I'll definitely try both. OOP is my addiction anyway... I also want to give credit to Mr Damian Conway.
In my opinion, he has written one of the best programming books in (programming) history.
And I am very lucky that, the book is the "Object Oriented Perl." (http://www.manning.com/Conway/)
He provides a whole chapter on Class::Struct and Class::MethodMaker.
I think MakeMethods is written after the book is published!!
Thank you all!
| [reply] |
MethodMaker seems more compact than MakeMethods.
Yup -- Class::MakeMethods is definitely not a light-weight distribution; this is a result of its generality: Class::MethodMaker provides about 30 types of methods, while Class::MakeMethods provides hundreds of them.
Class::MakeMethods is so full-featured that it can serve as a replacement for the functionality provided by Class::MethodMaker, Class::Singleton, Class::Inheritable, Class::AccessorFast, and other such modules. If you only require the features that one of these smaller modules provides, then by all means feel free to use it, but if you need to combine all of these features, it's nice to have one module that does it all.
I think MakeMethods is written after the book is published!
Yes, Class::MakeMethods has only been around for the last two years or so.
| [reply] |