No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Parameter defaults
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 23 Apr 2006 21:06:32 +0200
Kurt Stoll schrieb:
>
> Note that with parametercmd we can make this slightly cleaner to use:
>
> Class create Car -parameter { {doors {[[self class] doors]}} }
> Car parametercmd doors
>
> Car doors 8
> Car create limo
> limo doors ; # ==> 8
> Car doors 5
> Car create minivan
> minivan doors ; # ==> 5
In order to get this still better working, i would recommend to create
a metaclass called Vehicle, which sets for every instance class the
default number of doors and provides as well the "parametercmd".
Class Vehicle -parameter {{doors 4}} -superclass Class
Vehicle create Car -parameter { {doors {[[self class] doors]}} }
Car create sedan
puts [sedan doors] ; # ==> 4
Car create limo -doors 8
puts [limo doors] ; # ==> 8
Car create minivan -doors 5
puts [minivan doors] ; # ==> 5
you can do as well
Car doors 20
Car create choo-choo-train
puts [choo-choo-train doors] ; # ==> 20
but i am not whether you will really want this...
I have developed a major overhaul of "parameter" and friends, it will
be certainly
feature compatible at this level.
Currently one can only specify a value or a command to be invoced at
instantiation
time of the object (as in the example above). In general there are
several situations
where the command should be executed e.g. the first time the variable
is accessed
or on each access of the variable. This is e.g. important, when only a
few instance
variables are used during lifetime of an object, and the the
instantiation command
is rather expensive (e.g. a database query), or when one wants live
updates on
the instance variables...
The new parameter replacement (called slots) is very flexible and much more
powerful, in many situations, it will be faster as well. It is as well
possible
to use the same idioms for mixins/filters (... add, delete) as well for
other
object/class relationsshipts (e.g. class, superclass) and for
user-values as well.
Stay tuned. Currently, i am still unsure whether to use and extend
the old interface (based on "parameter"), or to use for the more powerful
cases the new interface. i have still a lot of integration and testing
in front
of me. My intention is certainly to keep the suff described above
compatible,
even with the new implementation.
-gustaf neumann
Date: Sun, 23 Apr 2006 21:06:32 +0200
Kurt Stoll schrieb:
>
> Note that with parametercmd we can make this slightly cleaner to use:
>
> Class create Car -parameter { {doors {[[self class] doors]}} }
> Car parametercmd doors
>
> Car doors 8
> Car create limo
> limo doors ; # ==> 8
> Car doors 5
> Car create minivan
> minivan doors ; # ==> 5
In order to get this still better working, i would recommend to create
a metaclass called Vehicle, which sets for every instance class the
default number of doors and provides as well the "parametercmd".
Class Vehicle -parameter {{doors 4}} -superclass Class
Vehicle create Car -parameter { {doors {[[self class] doors]}} }
Car create sedan
puts [sedan doors] ; # ==> 4
Car create limo -doors 8
puts [limo doors] ; # ==> 8
Car create minivan -doors 5
puts [minivan doors] ; # ==> 5
you can do as well
Car doors 20
Car create choo-choo-train
puts [choo-choo-train doors] ; # ==> 20
but i am not whether you will really want this...
I have developed a major overhaul of "parameter" and friends, it will
be certainly
feature compatible at this level.
Currently one can only specify a value or a command to be invoced at
instantiation
time of the object (as in the example above). In general there are
several situations
where the command should be executed e.g. the first time the variable
is accessed
or on each access of the variable. This is e.g. important, when only a
few instance
variables are used during lifetime of an object, and the the
instantiation command
is rather expensive (e.g. a database query), or when one wants live
updates on
the instance variables...
The new parameter replacement (called slots) is very flexible and much more
powerful, in many situations, it will be faster as well. It is as well
possible
to use the same idioms for mixins/filters (... add, delete) as well for
other
object/class relationsshipts (e.g. class, superclass) and for
user-values as well.
Stay tuned. Currently, i am still unsure whether to use and extend
the old interface (based on "parameter"), or to use for the more powerful
cases the new interface. i have still a lot of integration and testing
in front
of me. My intention is certainly to keep the suff described above
compatible,
even with the new implementation.
-gustaf neumann