Problem extending (adding methods) to class

David A. Black wrote:

Why not use a module?

module MyForm
attr_accessor :myfields
def get_fields
@myfields
end
end

class Ncurses::Form::FORM
include MyForm
end

Interesting. But sorry if I am missing something. as I understand it, i
can’t subclass a module, nor class Ncurses::Form::FORM. So i wont be
able to subclass this, right ?

Hi –

On Fri, 3 Oct 2008, Nit K. wrote:

class Ncurses::Form::FORM
include MyForm
end

Interesting. But sorry if I am missing something. as I understand it, i
can’t subclass a module, nor class Ncurses::Form::FORM. So i wont be
able to subclass this, right ?

It would still have the same ‘new’ issue. I’m suggesting, though, that
modules might be a good alternative to subclassing.

David

So my question again is: are classes declared within a module
typically/always factory classes like this – i mean with singleton new
methods?

Singleton new methods are rare (IO.new, Class.new, Struct.new …) and
out of these only IO gives the expected behavior when you subclass i.e
Subclass.new.class == Subclass.
Classes defined inside modules are primarily for namespacing.

Perhaps I should look thru the source code of Facets or some other
project to jump-start my ruby. Any suggestions?

Sure Facets has plenty of code samples. RubyQuiz is another.

–Cheers
–Ragav

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.