[Xotcl] Mixins in XOTcl

[Gustaf Neumann]

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