------Original Message------ From: uwe.zdun@uni-essen.de To: Zoran Vasiljevic zoran@munich.com Sent: December 13, 2000 9:55:56 AM GMT
- However, in the "mixin" case we could enable argument passing,
because "mixin" has just one argument? The rest could be passed > to
"init". any objections?
obj mixin Foo arg1 arg2 arg3
would pass arg1-arg3 to init of Foo. Right?
obj mixin [list Foo Bar] arg1 arg2 arg3
would pass arg1-arg3 to init of Foo AND of Bar. Right again?
Is so, then I think it should be done, if possible. 0.85 ? 0.9 ?
Cheer's, Zoran
______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup
"ZV" == Zoran Vasiljevic zoran@munich.com writes:
ZV> ------Original Message------ ZV> From: uwe.zdun@uni-essen.de ZV> To: Zoran Vasiljevic zoran@munich.com ZV> Sent: December 13, 2000 9:55:56 AM GMT
- However, in the "mixin" case we could enable argument passing,
because "mixin" has just one argument? The rest could be passed > to
ZV> "init". any objections?
ZV> obj mixin Foo arg1 arg2 arg3
ZV> would pass arg1-arg3 to init of Foo. Right?
yes
ZV> obj mixin [list Foo Bar] arg1 arg2 arg3
ZV> would pass arg1-arg3 to init of Foo AND of Bar. Right again?
yes
ZV> Is so, then I think it should be done, if possible. 0.85 ? 0.9 ?
if there are no objections we can include this right now (and officially in 0.84) ... its just a little change ... Just exchange the appended XOTclOMixinMethod in xotcl.c and re-compile to test it:
################################################# Class A A instproc init args {puts [self class]--$args;next} Class C C instproc init args {puts [self class]--$args;next}
Class B B instproc init args {puts [self class]--$args;next}
B b # every thing works puts ++++++++++++++++++++++++++ b mixin A arg1 arg2 arg3 puts ++++++++++++++++++++++++++ b mixin {A C} arg1 arg2 puts ++++++++++++++++++++++++++ b mixin {A C} arg1 puts ++++++++++++++++++++++++++ b mixin {A C}
# but here we have to add the args ... because "mixin" # is called before "init" puts ++++++++++++++++++++++++++ B b2 a1 a2 a3 -mixin {A C} puts ++++++++++++++++++++++++++ B b2 a1 a2 a3 -mixin {A C} a1 a2 a3
#################################################
--Uwe
"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
"GN" == Gustaf Neumann Gustaf.Neumann@wu-wien.ac.at writes:
"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 ?
GN> from the implementation point of view this is not a big issue. GN> however, from my experience, i should note that i switched from a GN> style of "passing arguments to init" to the "-parameter style of GN> configuring objects", which is in almost all cases the more elegant GN> solution.
GN> With your example, you will run into a similar problem when GN> multiple mixins are registered.
GN> a) Consider the following example:
GN> [Class C] instproc init {a} {puts "[self class] $a"; next} GN> [Class M1] instproc init {b} {puts "[self class] $b"; next} GN> [Class M2] instproc init {c} {puts "[self class] $c"; next}
GN> C c1 3 -mixin {M1 M2}
GN> here passing one argument to the mixin method should work GN> (weirdly enough, the argument is before the -mixin, but would GN> have similar semantics as
GN> C c1 3 GN> c1 mixin {M1 M2} 3
GN> but who says, that the arguments a b and c have the same GN> intended semantics? ... using -parameter is much clearer
sure ... but "args" as argument wouldn't yield that behavior
-parameter is surely the better solution. But if you want some more behavior in "init" then -parameter does, you need the constructor. There is currently no way to get that argument into the mixin constructor.
Moreover, for a newbie the error message may be hard to understand, if you do not associate "mixin" with "init".
GN> b) Then we have the factoring problem: what, if M1 and M2 have the GN> different argument lists. we could use something like:
GN> c1 mixin {M1 M2} {3 {a b}}
GN> but isn't that ugly?
that is the general problem I sketched in the first mail .. it also appears for ordinary class composition with two different constructors. You can build all these weird constructs also with ordinary class constructors.
Again "args" should be used ... or something else then the constructor. E.g. -paramter or -xyz
GN> this makes the manipulation of the mixin list (eg. automatically GN> inserting a mixin, if it is not there) by a program over-complicated.
GN> c) From the idea, mixins are orthogonal to the intrinsic classes GN> and can used for different classes as well. Should not the following GN> work somehow as well?
GN> [Class D] instproc init {x y} {puts "[self class] $x $y"; next} GN> D d1 a b -mixin M1
it seems to work in the extended version as expected:
% Class D D % D instproc init {x y} {puts "[self class] $x $y"; next} % Class M1 M1 % D d1 a b -mixin M1 ::D a b d1
However, it is not very elegant.
Let us consider Zoran' exmaple:
Class Tree ;# has abstract methods mostly Class XmlTree -superclass Tree ;# implements above methods Class UfsTree -superclass Tree ;# ...
XmlTree instproc init {xmlFile} {....} UfsTree instproc init {rootDir} {....}
Tree t t mixin XmlTree /path/to/xmlfile.xml ;# use the Xml driver t mixin UfsTree /some/dir ;# switch to filesystem driver
Here, the problem simply is that "-parameter" and other "-" methods are not evaluated before the constructor. Withour arguments for mixin you have no chance to get the vars into the constructor.
BTW, from the idea of class composability the mixin inits in this exmaple should either have an "args" argument or no "next" call. Or arguments could be given in pairs, like "-xmlFile path/to/xmlfile.xml -rootDir /some/dir".
Regards,
Uwe
-
Gustaf Neumann -
uwe.zdun＠uni-essen.de -
Zoran Vasiljevic