From: Sean O'Halpin <sean.ohalpin@...>
Date: 2005-11-23T23:26:18+09:00
Subject: Re: pattern: auto-running module init code

On 11/23/05, Phil Tomson <ptkwt@aracnet.com> wrote:
> Ah, that would be too simple ;-)  And the user of the module has to remember
> to call 'super' somewhere in the constructor, I was trying for something more
> automatic :)

With your scheme, the user has to remember to call extend in the
initialize method, rather than include at the class level. I've seen
modules that require this cause quite a bit of confusion
unfortunately.

> Hmmm...This brings up another thought:  Just like C++ programmers are often
> advised to go ahead and make their methods virtual in case someone comes along
> and subclasses, should we be generally calling super in our constructors in case
> someone comes along and mixes-in a module with an 'initialize' method defined?

Well, I'm beginning to do this as a matter of course - it really does
make all this kind of stuff much simpler once you get into the habit.

>>module Mod
>>  def self.included(obj)
>>    puts "in Mod"
>>  end
>>end

> Perhaps, but isn't 'obj' in this case actually the including class?

Yes, but I think of it as an object (too much playing about with singletons!).

[snip stuff about Module.included]

> So any
> initialization code you want to run by using 'included' will be class-level
> initialization, not instance-level.  That may or may not be what you want.

Indeed - it depends on what level you are trying to have the funky stuff happen.
I guess it's not really relevant to what you were trying to do. Sorry
for the noise!

Regards,

Sean