Xotcl April 2006

xotcl@alice.wu.ac.at

6 participants
5 discussions

Parameter defaults
by Kurt Stoll 23 Apr '06

23 Apr '06

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

2 1

C extensions
by Kristoffer Lawson 12 Apr '06

12 Apr '06

Are there any plans to have a real public interface for building methods and objects in C sometime in the near future? Like XOTCL_STUBS or whatever. As projects increase in size and complexity there are points when it would be increasingly beneficial to be able to move bits to C, mainly for performance reasons. I realise there are interfaces that offer this functionality, but it is my understanding that they are still under development and not set in stone, so it is natural to be wary about them. / http://www.fishpool.com/~setok/

1 0

Questions about the Serializer
by Scott Gargash 12 Apr '06

12 Apr '06

I'm using XOTcl objects to control hardware, and I'm trying to use the Serializer to persist hardware configurations. However, I've run into a couple of issues. 1) Not all of the object state is the consistent across serialization/deserialization. The hardware handle, for instance, may not be the same at deserialization time as it was when serialization occurred. What I'd like to do is remap some member variables to un-substituted variables ("-set hwhandle $handle" instead of "-set hwhandle 0x1234"), and then I'll set the variable to the correct value when restoring the configuration. I see a way to ignore variables and a way to remap object names, but is there a way to remap variables? Short of a global regsub on "Serializer deepSerialize" return result, that is? 2) The serializer bypasses initialization (-noinit), and basically just restores the internal state of the object. But in my application, I need to bring the hardware state into sync with the xotcl object, so just setting xotcl state variables doesn't suffice. Is there an easy way when deserializing to have some code executed after the object's state has all been restored? Something like a -noinit flag, but instead have a custom -init? Maybe instead of "-noinit", objects should have a "-init method" flag that determines the initialization mechanism? If the flag is not set, or is set to "init", the "init" method is invoked (default behavior), if the flag is set to some arbitrary method ("-init hwsync"), that arbitrary method gets invoked, and if the flag is set to an empty list ("-init {}"), no init method is invoked. Scott Notice The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by you in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please delete it and contact the sender immediately. Thank you.

2 1

patch to compile xotcl 1.4.0 w/tcl 8.5a4
by Steve Redler IV 11 Apr '06

11 Apr '06

diff -ruN xotcl-1.4.0/generic/xotcl.c xotcl-1.4.0sriv/generic/xotcl.c --- xotcl-1.4.0/generic/xotcl.c 2006-02-23 12:41:47.000000000 -0500 +++ xotcl-1.4.0sriv/generic/xotcl.c 2006-04-11 08:44:47.000000000 -0400 @@ -1706,16 +1706,18 @@ int instanceOpt, int resetOpt) { int valueLength, mustCopy = 1, format = 0; char *valueString, *c; - Tcl_Obj *valueObject, *result = NULL, *savedResult = NULL; + Tcl_Obj *valueObject, *result = NULL, *savedResult = NULL, *incrPtr;; XOTcl_FrameDecls; int flgs = TCL_LEAVE_ERR_MSG; XOTcl_PushFrame(in, obj); if (obj->nsPtr) flgs |= TCL_NAMESPACE_ONLY; + + incrPtr = Tcl_NewIntObj(1); #ifndef PRE83 - valueObject = TclIncrVar2(in, XOTclGlobalObjects[XOTE_AUTONAMES], name, 1, flgs); + valueObject = TclIncrObjVar2(in, XOTclGlobalObjects[XOTE_AUTONAMES], name, incrPtr, flgs); #else valueObject = TclIncrVar2(in, XOTclGlobalObjects[XOTE_AUTONAMES], name, 1, 0); #endif -- Regards, Steve Redler IV, SR Technology steve #@ sr-tech.com SR Tech Secure Webmail

1 0

(no subject)
by Ron 10 Apr '06

10 Apr '06

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Xotcl April 2006