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@alice.wu-wien.ac.at [mailto:xotcl-admin@alice.wu-wien.ac.at]Im Auftrag von Gustaf Neumann Gesendet: Freitag, 21. Mai 2004 20:09 An: Adam Turoff Cc: xotcl@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@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl