From: Robert Klemme <shortcutter@...>
Date: 2006-05-24T16:14:36+09:00
Subject: Re: initializing instance variables in a module

2006/5/23, Jeff Rose <rosejn@gmail.com>:
> > This thread seems to have gone astray a bit but I didn't see this
> > solution which I regard the standard way to handle this. The important
> > part is to use initialize(*a,&b) in the module. I've put this on the
> > wiki for easier reference:
> >
> > http://wiki.rubygarden.org/Ruby/page/show/InitializingWithInheritance
> >
> > Kind regards
> >
> > robert
>
> This doesn't really solve the problem.  The idea is that you don't want
> the including class to have to do anything related to initialization of
> the module(s) being included.

It doesn't have to.

>  In your example any including class would
> have to call super in order to make it work.

But this is true for classes inheriting anyway. You could even make it
yourself a habit to even call super if you do not inherit specifically
(i.e. inherit Obect).

>  If Derived implements an
> initialize method and doesn't call super then the module isn't
> initialized.  But why should it call super, it isn't deriving from
> anything, it is mixing it in.

I don't fully agree: Derived actually inherits from Base so it's
standard procedure to invoke the super class initialize.  If you then
write your module initialize with signature (*a,&b) you can insert it
into *any* inheritance chain that obeys the basic behavior without
doing any harm or losing initialization code.

> The two options Matz mentioned are the way to go.  Either a callback
> (module_initialize), which will act as an initialization method for the
> module, or the ability for the module to insert its own method(s)
> before, after, or around the class that includes it.  (CLOS method
> combinations...  AOP)

Well, yes, if a change to the language / lib can be considered these
are probably better.

Kind regards

robert

-- 
Have a look: http://www.flickr.com/photos/fussel-foto/