It would still have the same 'new' issue. I'm suggesting, though, that
modules might be a good alternative to subclassing.
David
But modules can't maintain state, right.
While refactoring, i began dumping a lot of methods in a Module.
Then i needed differential behavior based on "kind_of", e.g. a basic
key_handler, a key_handler for tabular forms etc. The cleanest way that
i could think of was having the form objects having their own key
handling.
So i needed to differentiate forms based on behaviour. Thus I have a
heirarchy of forms and applications. The appropriate handler is called
based on what kind of form was created.
I am really new here, and struggling with concepts, but i understand
that yuo can have only one parent/super class, so modules help out in
acquiring more behavior (sort of multiple inheritance).
I'm suggesting, though, that
modules might be a good alternative to subclassing.
However, in the subclassing I am doing, the objects my application
consists of (composition) are descending from their own super-classes.
Yes, they still call "static" methods of the original module i created
(i mean convenience methods like printing errors, statuses etc).
This is why i was asking (on another thread, too) of actual projects
whose source one can learn these things from ( as against books,
samples, examples etc of which i have read enough - but will keep
reading!).
Perhaps the ruby source itself will be good quality - i really need to
see how real-life medium size projects in ruby are organized, classed
etc.