No registered users in community xowiki
in last 10 minutes
in last 10 minutes
[Xotcl] Parameter defaults
From: Kurt Stoll <stoll_at_mac.com>
Date: Sun, 23 Apr 2006 10:58:07 -0700
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
Date: Sun, 23 Apr 2006 10:58:07 -0700
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