[Xotcl] Parameter defaults

[Gustaf Neumann]

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