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 21:20:23 +0100
On 19 May 2004, at 21:05, Michael Schlenker wrote:
>> 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.
What do you mean here? Variables are mutable, yes. They're not
"objects" though (they're neither XOTcl objects, or even Tcl_Objs
(values) - I assume they're normal Tcl namespaced variables, but XOTcl
might implement them differently). I'm proposing a change of interface
that's all. At present we have a "special" variable (the mixin list)
which is hidden behind the [$obj mixin] and [$obj info mixin] commands.
All I am saying is to bring that variable into the limelight to be an
actual instance variable of the object, and use the usual methods to
alter it. It's always been mutable, just not in place.
(By "immutable" I would be referring to something like a "final"
variable in Java - you can assign to it once, but never again.)
>
>> 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... ;-)
Not in all languages! C.f. prolog, various rule interpreters etc. Of
course, that's probably an abuse of the term "variable", but I
digress... :^)
>
>> 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.
Well, you have magic variables now - they're just hidden behind the
[$obj info mixins]/[$obj mixin]. The difference I was proposing was to
get rid of these special methods, and replace them with a regular
instance variable:
$obj lappend mixinlist $somemixin
$obj set mixinlist [linsert [$obj set mixinlist] 0 $newMixin]
etc
Just a trade off between altering the list in the "standard" way using
the normal variable methods, or via a set of additional mixin-specific
methods (the mixin_prepend etc that were proposed). Note this has
nothing to do with mutable values vs accessor methods: the only way you
can get/set an instance variable is via [$obj set] so it's already
hidden behind accessor functions (oh, there's the instvar stuff, but
I've never really looked at that).
Yes, it would add a "magic" variable name, but remove some "magic"
methods. I was just seeing what appeared to be a proposal to mirror all
of the variable manipulation commands with special ones to deal with
mixins, which seemed a bit of a waste.
Cheers,
Neil.
Date: Wed, 19 May 2004 21:20:23 +0100
On 19 May 2004, at 21:05, Michael Schlenker wrote:
>> 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.
What do you mean here? Variables are mutable, yes. They're not
"objects" though (they're neither XOTcl objects, or even Tcl_Objs
(values) - I assume they're normal Tcl namespaced variables, but XOTcl
might implement them differently). I'm proposing a change of interface
that's all. At present we have a "special" variable (the mixin list)
which is hidden behind the [$obj mixin] and [$obj info mixin] commands.
All I am saying is to bring that variable into the limelight to be an
actual instance variable of the object, and use the usual methods to
alter it. It's always been mutable, just not in place.
(By "immutable" I would be referring to something like a "final"
variable in Java - you can assign to it once, but never again.)
>
>> 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... ;-)
Not in all languages! C.f. prolog, various rule interpreters etc. Of
course, that's probably an abuse of the term "variable", but I
digress... :^)
>
>> 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.
Well, you have magic variables now - they're just hidden behind the
[$obj info mixins]/[$obj mixin]. The difference I was proposing was to
get rid of these special methods, and replace them with a regular
instance variable:
$obj lappend mixinlist $somemixin
$obj set mixinlist [linsert [$obj set mixinlist] 0 $newMixin]
etc
Just a trade off between altering the list in the "standard" way using
the normal variable methods, or via a set of additional mixin-specific
methods (the mixin_prepend etc that were proposed). Note this has
nothing to do with mutable values vs accessor methods: the only way you
can get/set an instance variable is via [$obj set] so it's already
hidden behind accessor functions (oh, there's the instvar stuff, but
I've never really looked at that).
Yes, it would add a "magic" variable name, but remove some "magic"
methods. I was just seeing what appeared to be a proposal to mirror all
of the variable manipulation commands with special ones to deal with
mixins, which seemed a bit of a waste.
Cheers,
Neil.