Re: [Xotcl] Mixins in XOTcl

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Sat, 22 May 2004 12:29:41 +0200

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
>