No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Mixins in XOTcl
From: Neil Madden <nem_at_cs.nott.ac.uk>
Date: Wed, 19 May 2004 17:08:01 +0100
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.
Date: Wed, 19 May 2004 17:08:01 +0100
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.