https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112015-09-25T11:08:46ZRuby Issue Tracking SystemRuby master - Feature #11550: Current behaviour of super(...) is dangerous in the presence of more than one included modules.https://bugs.ruby-lang.org/issues/11550?journal_id=542772015-09-25T11:08:46ZEregon (Benoit Daloze)
<ul></ul><p>Why not simply having <code>super</code> in M1 and M2 #initialize?<br>
All constructors should call <code>super</code>, unless they just inherit from Object/BasicObject.</p> Ruby master - Feature #11550: Current behaviour of super(...) is dangerous in the presence of more than one included modules.https://bugs.ruby-lang.org/issues/11550?journal_id=544242015-10-12T10:47:46Zrovf (Ronald Fischer)ynnor@mm.st
<ul></ul><p>Benoit Daloze wrote:</p>
<blockquote>
<p>Why not simply having <code>super</code> in M1 and M2 #initialize?<br>
All constructors should call <code>super</code>, unless they just inherit from Object/BasicObject.</p>
</blockquote>
<p>First, M1 and M2 don't know where they are going to be mixed in, so they can not invoke <code>suuper</code> - they don't know what parameters are being passed.</p>
<p>Second, the class which mixes in M1 and M2 needs to initialize two modules, which is not possible with the current language.</p> Ruby master - Feature #11550: Current behaviour of super(...) is dangerous in the presence of more than one included modules.https://bugs.ruby-lang.org/issues/11550?journal_id=544272015-10-12T12:54:54ZEregon (Benoit Daloze)
<ul></ul><p>Ronald Fischer wrote:</p>
<blockquote>
<p>First, M1 and M2 don't know where they are going to be mixed in, so they can not invoke <code>suuper</code> - they don't know what parameters are being passed.</p>
<p>Second, the class which mixes in M1 and M2 needs to initialize two modules, which is not possible with the current language.</p>
</blockquote>
<p>Would</p>
<pre><code>module M1
def initialize(*)
super
end
end
</code></pre>
<p>work for your use case?<br>
Then the whole hierarchy can be initialized by just calling super.</p> Ruby master - Feature #11550: Current behaviour of super(...) is dangerous in the presence of more than one included modules.https://bugs.ruby-lang.org/issues/11550?journal_id=561882016-01-20T08:44:00Zrovf (Ronald Fischer)ynnor@mm.st
<ul></ul><p>Benoit Daloze wrote:</p>
<blockquote>
<p>Ronald Fischer wrote:</p>
<blockquote>
<p>First, M1 and M2 don't know where they are going to be mixed in, so they can not invoke <code>suuper</code> - they don't know what parameters are being passed.</p>
<p>Second, the class which mixes in M1 and M2 needs to initialize two modules, which is not possible with the current language.</p>
</blockquote>
<p>Would</p>
<pre><code>module M1
def initialize(*)
super
end
end
</code></pre>
<p>work for your use case?<br>
Then the whole hierarchy can be initialized by just calling super.</p>
</blockquote>
<p>This doesn't help either. It is not a problem of the correct number of parameters, but of the semantics. Even in your design, there is no way that class C can tell to the modules M1 and M2, which parameters should be used for each respective module, UNLESS the modules cooperate in the protocol.</p>
<p>For example, if each module allows an arbitrary list of named parameters, but picks from this list exactly the parameter which has a key (name) of the name of this module, the constructor of C could write</p>
<pre><code>super(M1: [3,5,8], M2: %w(foo bar))
</code></pre>
<p>and M1 would use the parameters 3,5,8 and M2 would use the parameters foo and bar.</p>
<p>While this would work (and, IMHO, be even a very useful way), it would require that all modules use the same convention for parameter passing. I can do this in my own application, when I am designing my modules, but it doesn't work well when I publish a module for general use.</p>