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.