From: Robert Klemme Date: 2012-02-22T01:27:35+09:00 Subject: Re: Difference between 1.9.2 and 1.9.3 2012/2/21 Bartosz Dziewoński : > 2012/2/21 Robert Klemme : >> _Exactly_ as I said: >> >> ~$ diff -U5 x.rb xx.rb >> --- x.rb        2012-02-21 16:38:04.791899100 +0100 >> +++ xx.rb       2012-02-21 16:40:38.587789800 +0100 >> @@ -18,11 +18,11 @@ >>  end >> >>  class D >>  include A >>  def initialize(name) >> -   super >> +   super() >>  end >>  end >> >>  B.new('foo') >>  D.new('bar') > > I think the point is that this will not pass the arguments to module's > #initialize. But arguments are not uses in the example and there was no statement which would indicate that fact. James, what is it that you really need? It's generally problematic to have module initialization with arguments: if you have a module which needs arguments for initialization you limit the usability because all classes using it must be aware of this fact (i.e. pass proper arguments). Plus, all these classes must have a superclass or (supermodule, i.e. next module in inheritance chain!) constructor with the exact same number and order of arguments because the module constructor must decide how to pass stuff on. I think that interferes with the concept of "mix in" module which you can use in many places and even add to classes later on. You can remedy that a bit by doing something like this in a module's initialize # Will read first argument as name if present def initialize(*a, &b) @name = a.first # nil if missing end If there is so much common state to initialize then this might be an indication of more tight coupling between class D and B or C and that it might be better to change the inheritance hierarchy (i.e. make D inherit B as well). Generally inheritance initialization is tricky in a language with so much dynamic where the inheritance hierarchy can change any time... Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/