I was in the process of writing this email to ask whether XOTcl currently supports, or could easily be extended to support, a particular pattern of parameter defaults that I often use, and then was pleased to discover that XOTcl already provides most of what I was looking for. Though, it's not documented as such, so I'm not certain whether this was intentional. I suspect it may have been a side effect of the generality of parameters. I don't mean to dismiss the foresight of the XOTcl authors, but since it is a simple mechanism, and not documented, I am concerned that the feature may disappear in the future.

The pattern is simple - parameter defaults, instead of being constants, should be changeable so that client code can modify the defaults as desired. For example, if the default is a class variable, then client code can modify the class variable. Then, when a new instance is created, the new default is used. To extend the example from the tutorial:

Car set doors 8 Car create limo limo doors ; # ==> 8 Car set doors 5 Car create minivan minivan doors ; # ==> 5

I originally supported this pattern by putting the appropriate intelligence in the init instproc. But, since I use this pattern a lot, I saw that code commonly in many of my init instprocs. So, I was looking to find a way to have XOTcl automatically pick up the default from the class. I decided that the most general thing to do was to put a script in the default and then execute it. But, when I tried that, I found that XOTcl executed the script for me! So, to support the above, I simply did:

Class create Car -parameter { {doors {[[self class] set doors]}} }

I also found that the default can be a simple variable, though accessing it requires scope qualifiers (but, I find this much less useful):

Class create Car -parameter { {doors $::DOORS} } set DOORS 4 Car create sedan sedan doors ; # ==> 4

Obviously, XOTcl supports much more general default behavior than I was originally looking for. But, for me, this is the appropriate solution. I can express simple defaults very simply. If I am looking for something more complicated, I can create a proc to support it, and then have the proc called.

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

This then begs for automatic creation of the parametercmd on the class. I had hoped that this could be accomplished by subclassing Class::Parameter and extending the init instproc (note that I had to actually use ::xotcl::Class::Parameter), but this did not work:

Class MyParameter -superclass ::xotcl::Class::Parameter MyParameter instproc init args { ## I would like to create parametercmd's on the class here; but, I need a handle ## to the class. Is it one of the args? Let's find out: puts [info level 0] next } Class create Car -parameterclass MyParameter -parameter { {color green} } ## Hmm - didn't see what I hoped I would see. Car create ferrari ## init ::ferrari ## ::ferrari ## Ok, this is where the parameter gets instantiated. So, how do the instparametercmd's get created?

Maybe there is no hook for me to do what I'm trying to do? Maybe I just have to accept manually adding the parametercmd to the class? It's not such a big deal, but I thought it might be useful.

Thanks, Kurt Stoll