No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Mixins in XOTcl
From: Michael Schlenker <schlenk_at_uni-oldenburg.de>
Date: Wed, 19 May 2004 22:05:21 +0200
Neil Madden wrote:
>
> On 19 May 2004, at 17:07, Michael Schlenker wrote:
>
>> Kristoffer Lawson wrote:
>>
>>> On Wed, 19 May 2004, Michael Schlenker wrote:
>>>
>>>> Its similar in tcl, where you have [info commands] and not a magic
>>>> $commands variable as you might have in other languages.
>>>>
>>>> Using traces it should be possible to provide such an interface if
>>>> anyone really wants it.
>>>
>>>
>>> So what is so problematic about just getting a list, manipulating it
>>> and
>>> then setting it back? Seems like a lot of copied effort for what is
>>> basically just list manipulation.
>>>
>> Yep. I refer to Adam and Neil who both wanted to have mutable objects
>> instead of accessor functions.
>> Its the usual problem with mutable list objects and the tradional
>> value based list operations in Tcl.
>
> Woah there! I said nothing about mutable objects/values.
You talked about adding instance variables which are mutable objects by
definition, while Adam talked about mutable objects directly.
> Mutable variables are all that is needed, and they exist already (in
> fact, you have to go an extra step to get immutable variables).
Of course, mutability is what variables are all about... ;-)
> The idea is to reuse things like [lappend], [linsert], [lreplace] etc,
> without creating lots of [mixin_append], [mixin_replace] etc etc.
> That's the duplication of effort.
You can reuse them, correct me if I'm wrong:
set mixins [$obj info mixins]
# use standard list operations as you like
set mixins [linsert $mixins 0 $newMixin]
lappend mixins $anotherMixin
$obj mixin $mixins
Where is the huge benefit of a magic instance variable containing the
list of mixins? I just don't see the benefit, but i see that you would
add a magic variable name to objects where none existed before.
Either the interface gets cluttered with commands (prepend append
llength whatever) or the existing commands are reused which leads to
slightly longer code but smaller interfaces.
Michael
Date: Wed, 19 May 2004 22:05:21 +0200
Neil Madden wrote:
>
> On 19 May 2004, at 17:07, Michael Schlenker wrote:
>
>> Kristoffer Lawson wrote:
>>
>>> On Wed, 19 May 2004, Michael Schlenker wrote:
>>>
>>>> Its similar in tcl, where you have [info commands] and not a magic
>>>> $commands variable as you might have in other languages.
>>>>
>>>> Using traces it should be possible to provide such an interface if
>>>> anyone really wants it.
>>>
>>>
>>> So what is so problematic about just getting a list, manipulating it
>>> and
>>> then setting it back? Seems like a lot of copied effort for what is
>>> basically just list manipulation.
>>>
>> Yep. I refer to Adam and Neil who both wanted to have mutable objects
>> instead of accessor functions.
>> Its the usual problem with mutable list objects and the tradional
>> value based list operations in Tcl.
>
> Woah there! I said nothing about mutable objects/values.
You talked about adding instance variables which are mutable objects by
definition, while Adam talked about mutable objects directly.
> Mutable variables are all that is needed, and they exist already (in
> fact, you have to go an extra step to get immutable variables).
Of course, mutability is what variables are all about... ;-)
> The idea is to reuse things like [lappend], [linsert], [lreplace] etc,
> without creating lots of [mixin_append], [mixin_replace] etc etc.
> That's the duplication of effort.
You can reuse them, correct me if I'm wrong:
set mixins [$obj info mixins]
# use standard list operations as you like
set mixins [linsert $mixins 0 $newMixin]
lappend mixins $anotherMixin
$obj mixin $mixins
Where is the huge benefit of a magic instance variable containing the
list of mixins? I just don't see the benefit, but i see that you would
add a magic variable name to objects where none existed before.
Either the interface gets cluttered with commands (prepend append
llength whatever) or the existing commands are reused which leads to
slightly longer code but smaller interfaces.
Michael