No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Mixins in XOTcl
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 21 May 2004 20:08:37 +0200
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
Date: Fri, 21 May 2004 20:08:37 +0200
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