[Xotcl] Mixins in XOTcl

Neil Madden nem at cs.nott.ac.uk
Wed May 19 18:08:01 CEST 2004


On 19 May 2004, at 16:37, Michael Schlenker wrote:

> Neil Madden wrote:
>
>> Just a random thought, not totally paying attention to this thread:
>>
>> Is there a reason why the filter/mixin lists could not just be normal 
>> object/class variables? Seems XOTcl already has plenty of flexibility 
>> to deal with these. E.g.:
>>
>> instead of:
>>
>> Object mixin ....
>>
>> do:
>>
>> Object set mixins [list ... ]
>>
>> or something like that (not completely familiar with the current 
>> syntax). The old methods could be setup to just be wrappers around 
>> these new variables. Or is there some reason why these lists are 
>> treated specially?
>
> mixins and filters are no variables.

No, but a list of them can be put in a variable.

> Its similar in tcl, where you have [info commands] and not a magic 
> $commands variable as you might have in other languages.

The reason for this is that commands are not first class, but are 
instead implemented as a handle - you never get a first class command 
value in Tcl (currently, see recent TIPs though), so you'd have nothing 
to store in the variable (just another name, which has to be resolved 
somewhere). This leads to a duplication of manipulator commands for 
vars and commands:

set var value		-> proc name ... / interp alias
set var			-> info args/info default/info body
unset var			-> rename cmd {}

etc, etc. This duplication of commands is what appears to be happening 
for mixins/filters too. However, we are not storing mixins themselves 
in this scheme, but the handles to them - which are in fact, 
first-class. The fact that these handles are themselves command names, 
which are already handled specially by Tcl, allows us to resolve them 
without an infinite recursion.

There was another post about pre-processing which is done on mixin 
lists (resolving names, removing duplicates etc). This is a better 
argument, as it points out that wrappers would be needed anyway, so 
looks like  duplication of methods is unavoidable (at least, not 
without more thought).

Cheers,

Neil.




More information about the Xotcl mailing list