[Xotcl] Mixins in XOTcl

[Uwe Zdun]

Hello,

my 2 cents: I liked the earlier proposal with the "interceptor" method
better
than this delegator,because it is more XOTcl style. I think it is important
to have one kind of
interface; we always use methods on the object itself, not methods that
delegate.
That's also the reason why I don't think the magic variable should be
introduced: it is
simply not Tcl style to have magic variables. Even though both ideas are
appealing, I think
sticking to Tcl/XOTcl style is important.
I agree with the critic on the term interceptor:
the interfaces for filters and mixins should be distinct: they are different
concepts.
BTW, superclass lists could make use of the same interface: obviously here
the
term interceptor is not appropriate.

what about just extending the usually interfaces with new arguments, such
as:

A mixin X
A mixin add Z 3
A mixin add Y end
A mixin delete Y
A instmixin add T 1
A superclass B
A superclass add C

--uwe



> -----Ursprüngliche Nachricht-----
> Von: xotcl-admin at alice.wu-wien.ac.at
> [mailto:xotcl-admin at alice.wu-wien.ac.at]Im Auftrag von Gustaf Neumann
> Gesendet: Freitag, 21. Mai 2004 20:09
> An: Adam Turoff
> Cc: xotcl at alice.wu-wien.ac.at
> Betreff: Re: [Xotcl] Mixins in XOTcl
>
>
> On Wednesday 19 May 2004 17:03, Adam Turoff wrote:
> > > what do you people think about the following "interceptor"
> > > method: it is more verbous, but much more powerful as
> > >
> >
> > Hm...
> >
> > One minor niggle is the use of the term 'interceptor'.  The
> > term is quite overloaded.  First, this instproc manages two kinds of
> > 'interceptor'  interfaces for an object: mixins and filters.
> Second, the
> > proc itself  is an interceptor -- it traps calls to manage the mixin and
> > filter lists.  Third, as you have written this proc, it manages
> > both mixins and filters, which makes them appear more similar than they
> > really are.
>
>  what you said is certainly true. I have suggested the term with a
>  mindset that these two are "additional kind of interceptors normally
>  not supported by other languages" (similiar to the section "Message
>  Interception Techniques" in the tutorial).
>
>  Your concern seems to be mostly the "name" interceptor.
>  The commands have to do with what's sometimes is called
>  "write introspection" in analogy to "read introspection", where
>  you query some properties and relations of created artefacts.
>  The former lets you change some properties/relations.
>
>  The normal xotcl interface to (stack-independet) introspection
>  is the info command. The pattern to change things is
>
>     set old [X info PROPERTY]
>     X PROPERTY [modify $old]
>
>  where property is for example mixin, instmixin, filter, instfilter.
>  The same pattern works with some more properties
>  such as "superclass", or to some extend "class"
>  as well. Some of the read-introspectable tcl properties
>  such as [info body ...] or [info args] or [info default]
>  could be made writable as well, but the benefit
>  compared to a proc command would be relative small.
>
>  I am not a big friend of magic variables as base
>  mechanism, since otcl did not let me allow to use
>  "class" or "proc" as names of instance variables.
>  Methods are better since they can be easily refined.
>
>  Look at the following study; it does not have the
>  switch ugliness with different arglists, it is
>  extensible and interceptible:
>
>    Object introspection
>    introspection proc get {obj prop} {$obj info $prop}
>    introspection proc set {obj prop value} {$obj $prop $value}
>    introspection proc add {obj prop value {pos 0}} {
>       $obj $prop [linsert [$obj info $prop] $pos $value]
>    }
>    introspection proc delete {obj prop value} {
>       set old [$obj info $prop]
>       set p [lsearch -glob $old $value]
>       if {$p>-1} {$obj $prop [lreplace $old $p $p]} else {
> 	  error "$value is not a $prop of $obj ($old)"
>       }
>   }
>   introspection proc unknown {m args} {
>     puts "method '$m' unknown for [self]"
>     puts "   valid commands are: {[lsort [my info procs]]}"
>   }
>
> we can define a filter to see the consequences of
> our doings:
>
>   introspection proc i-filter {obj args} {
>     set r [next]
>     if {[string compare $args ""] && [my isobject $obj]} {
> 	set prop [lindex $args 0]
> 	puts "$prop of $obj = [$obj info $prop]"
>     }
>     return $r
>   }
>   introspection filter i-filter
>
> now we can try it out:
>
>    Object o1
>    introspection add o1 mixin A
>    introspection add o1 mixin B
>    introspection add o1 mixin C end
>    introspection delete o1 mixin *A
>    introspection delete o1 mixin *A
>
> well, we can shuffle the arguments in a little
> reflector instproc:
>
>   Object instproc introspection {cmd prop args} {
>       eval introspection $cmd [self] $prop $args
>   }
>   o1 introspection add mixin A
>
> and we have an "... introspection get ..." and friends again
> and get an error message for a
>
>    o1 introspection cancel mixin A
>
> .... but: i am not so happy about the name
> "introspection" in "introspection set" and
> "introspection add" as well, since it requires
> familiarity  with "write introspection"  which is
> not only a "*spection" in the sense of
> "looking into", but destructive.
>
> suggestions?
> -gustaf neumann
> --
> Univ.Prof. Dr.Gustaf Neumann
> Abteilung für Wirtschaftsinformatik
> WU-Wien, Augasse 2-6, 1090 Wien
> _______________________________________________
> Xotcl mailing list  -  Xotcl at alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>