Xotcl

xotcl@alice.wu.ac.at

2 participants
653 discussions

Issue with mixin delete
by Scott Gargash 09 May '06

09 May '06

Hello, I've run into an issue when trying to remove a mixin from an object. It appears that removing a mixin from an object interacts with the method chaining, such that the "next" isn't invoked. Here's an example: Class Mixin1 Mixin1 instproc destroy {args} { puts "Mixin1 1: [my info mixin]" next my mixin delete ::Mixin1 puts "Mixin1 2: [my info mixin]" } Class Mixin2 Mixin2 instproc destroy {args} { puts "Mixin2 1: [my info mixin]" my mixin delete ::Mixin2 puts "Mixin2 2: [my info mixin]" next } Class Mixin3 Mixin3 instproc destroy {args} { puts "Mixin3 1: [my info mixin]" my mixin delete ::Mixin3 puts "Mixin3 2: [my info mixin]" next } Object a puts "a: [a info mixin]" a mixin set {::Mixin1 ::Mixin2 ::Mixin3} puts "a: [a info mixin]" a destroy And the output is a: a: ::Mixin1 ::Mixin2 ::Mixin3 Mixin1 1: ::Mixin1 ::Mixin2 ::Mixin3 Mixin2 1: ::Mixin1 ::Mixin2 ::Mixin3 Mixin2 2: ::Mixin1 ::Mixin3 Mixin1 2: ::Mixin3 Because Mixin1 invokes "next" before "mixin delete", Mixin2's "destroy" method gets invoked. But since Mixin2 invokes "mixin delete" before "next", Mixin3's "destroy" method is not invoked, despite it remaining in the object's list of mixins. This is not the behavior I would expect, and I can't find it documented anywhere. Is this the intended behavior? What should I do if I want to remove a mixin and then continue executing chained methods. 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 9

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

Has anyone xotcl this for WindowsCE/Windows Mobile/Pocket PC
by Martin Kendall 29 Mar '06

29 Mar '06

As there are so many excellent ports of Tcl to the Pocket PC: http://wiki.tcl.tk/2946 http://wiki.tcl.tk/13487 http://www.evolane.com/software/etcl/ I wondered if anyone had compile xotcl to run with one of these before I embark on evC++ Thanks Martin

2 1

Re: AW: [Xotcl] destroy invoked by object move?
by Gustaf Neumann 27 Mar '06

27 Mar '06

Scott Gargash schrieb: > I've been thinking along somewhat different lines, the classic "extra > level of indirection" that solves all problems. What about using > interpreter aliases as an indirection? What would happen if all > objects were created as anonymous commands inside (say) the xotcl > namespace, and the object name was just an alias to the anonymous object? > you can do this easily by your own in xotcl. redefine e.g. unknown for classes (or provide a mixin for create), and create objects via new and add the alias. ==================================== Class instproc unknown {name args} { set o [eval my new $args] ::interp alias {} $name {} $o return $name } ==================================== so, now we can test the aliased content. it behaves in many respects the same, but when it comes to refer to "self" or to namespaces one would notice a different behavior: ==================================== Class create Person -parameter {age} Person p1 -age 123 puts [p1 age] puts [p1 self] ==================================== As you noted, one can switch in such a universe the aliases to "move" objects quickly. ==================================== Object instproc move {newname} { foreach a [::interp aliases] { if {[::interp alias {} $a] eq [self]} {set oldname $a;break} } ::interp alias {} $newname {} [self] ::interp alias {} $oldname {} } p1 move p2 puts [p2 age] puts [p2 self] ==================================== most probably, an associative array to keep the aliases is more efficient than the loop through all aliases, once there are many objects. Note, that "self" remains the same. If you need this kind of behavior for certain kind of objects, you can certainly use a base-class RefObject or whatever, and subclass the application classes from it.... This kind of objects will vertainly need a destroy method to delete the alias as well. -gustaf neumann

4 32

AW: [Xotcl] destroy invoked by object move?
by mail＠xdobry.de 17 Mar '06

17 Mar '06

Hi Scott! Indeed move in XOTcl is copy+destroy and it is implemented in XOTcl itself. %Object info instbody move if {[string compare [string trimleft $newName :] [string trimleft [::xotcl::self] :]]} { if {$newName != ""} { ::xotcl::my copy $newName} if {[::xotcl::my isclass [::xotcl::self]] && $newName != ""} { foreach subclass [::xotcl::my info subclass] { set scl [$subclass info superclass] if {[set index [lsearch -exact $scl [::xotcl::self]]] != -1} { set scl [lreplace $scl $index $index $newName] $subclass superclass $scl}} } ::xotcl::my destroy} So move it not rename references. Is it anyway good idea to rename references? So reference (object name) is its identity (what about dangling pointers). So time ago I wanted to program (movable) tree structures by using nested objects. Operation of moving tree items I have implented as move operation. After I have discovered, what indeed move is, I have changed the implementation. I think it is a little trap in XOTcl, because many user thinks it is magic fast and do not really destory objects. Indeed it is quite expensive. Artur

4 8

Changing a parameter's -setter function
by Scott Gargash 17 Mar '06

17 Mar '06

Hello, Is it possible to change the -setter command associated with a parameter at some point other than class definition? I want to trigger some side effects from a parameter set operation, but I can't trigger the side effects until after other things have been initialized, so I want to use the default setter method until the end of init, and then replace the setter method (but not the getter method). I can override create a parameter-named method at init time, but that overrides the getter along with the setter. I'd rather not have to handle the -getter from my proc (the default -getter is fine and 2.5x faster). I've looked through the docs and the tutorial and I can get tantalizingly close (parametercmd), but is there an easy way from within a proc to change the -setter properties of a parameter? Something like this: Class create a -parameter {{foo 1}} a instproc foosetter {var val} { # Do something with [self] that isn't valid pre-init } a instproc init {} { #override foo's -setter parameter cmd my parametercmd foo -setter foosetter } a create b -foo 234 ;# calls default foo setter b foo ;# calls default foo getter b foo 123 ;# calls overridden foosetter Thanks for your help. XOTcl is a great. It should be adopted as Tcl's standard OO package. 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 3

← Newer
1
...
26
27
28
29
30
31
32
...
66
Older →

Jump to page:

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