[Xotcl] Re: [Xotcl] RE: [Xotcl] Re: [Xotcl] Object mixin with passing init args ?

[uwe.zdun at uni-essen.de]

>>>>> "GN" == Gustaf Neumann <Gustaf.Neumann at wu-wien.ac.at> writes:

>>>>> "Z" == Zoran Vasiljevic <zoran at munich.com> writes:
Z> ------Original Message------
>>> 2. 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

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun at xotcl.org, uwe.zdun at uni-essen.de