"Z" == Zoran Vasiljevic zoran@munich.com writes:
Z> ------Original Message------
- However, in the "mixin" case we could enable argument passing,
because "mixin" has just one argument? The rest could be passed > to
Z> "init". any objections?
Z> obj mixin Foo arg1 arg2 arg3 Z> would pass arg1-arg3 to init of Foo. Right?
Z> obj mixin [list Foo Bar] arg1 arg2 arg3
Z> would pass arg1-arg3 to init of Foo AND of Bar. Right again?
Z> Is so, then I think it should be done, if possible. 0.85 ? 0.9 ?
from the implementation point of view this is not a big issue. however, from my experience, i should note that i switched from a style of "passing arguments to init" to the "-parameter style of configuring objects", which is in almost all cases the more elegant solution.
With your example, you will run into a similar problem when multiple mixins are registered.
a) Consider the following example:
[Class C] instproc init {a} {puts "[self class] $a"; next} [Class M1] instproc init {b} {puts "[self class] $b"; next} [Class M2] instproc init {c} {puts "[self class] $c"; next}
C c1 3 -mixin {M1 M2}
here passing one argument to the mixin method should work (weirdly enough, the argument is before the -mixin, but would have similar semantics as
C c1 3 c1 mixin {M1 M2} 3
but who says, that the arguments a b and c have the same intended semantics? ... using -parameter is much clearer
b) Then we have the factoring problem: what, if M1 and M2 have the different argument lists. we could use something like:
c1 mixin {M1 M2} {3 {a b}}
but isn't that ugly?
this makes the manipulation of the mixin list (eg. automatically inserting a mixin, if it is not there) by a program over-complicated.
c) From the idea, mixins are orthogonal to the intrinsic classes and can used for different classes as well. Should not the following work somehow as well?
[Class D] instproc init {x y} {puts "[self class] $x $y"; next} D d1 a b -mixin M1
I see your issue, bit we should not rush into implementation.
Greetings, -gustaf