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