Xotcl March 2006

xotcl@alice.wu.ac.at

8 participants
10 discussions

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

destroy invoked by object move?
by Scott Gargash 15 Mar '06

15 Mar '06

Hello, I'm trying to make a pool of managed resources. At the start-of-day, the pool is filled with a number of object instances. A client can retrieve an object instance from the pool, and I have a mixin class that overides destroy to automatically returns the instance to the pool upon destruction. The objects are all initially created as children of the pool, and it was my intent to have an acquiring object take ownership of the instance by move'ing the instance into itself. However, it seems that move'ing an object invokes the destroy method, which then triggers my mixin and returns it to the pool. It seems that move shouldn't destroy the object, as it's only renaming it. Is this the intended behavior? Would anything bad happen if, instead of move'ing the instance, I were to use Tcl's rename command to move the object? Is there a better way to get where I'm trying to go? Scott BTW, I notice there's not much activity on this mailing list. XOTcl's object model is sufficiently new to me that I've got lots of questions on the "right" way to do things, but I hate to be filling up everyone's mailbox. Is there a more appropriate place to be asking questions? 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.

1 0

Unforwarding object method
by Scott Gargash 13 Mar '06

13 Mar '06

Hello, I've just started looking at XOTcl over the last couple days, and so far I like it a lot. Since I'm still learning, I assume I've overlooked something in the documentation, but I can't find how to remove a forwarded method from an object. It seems that all I can do is add a forwarded method, but once installed, I can never unforward a method. Is this true? Here's an (simplified) example of what I'm trying to do: Object a a proc foo {args} { puts "a: [self] foo" } Object b b set overrides {} b proc foo {obj} { puts "b: [self] foo" if {-1 == [lsearch [my set overrides] $obj]} { puts "b is overriding $obj foo" $obj forward foo [self] overridefoo $obj } } b proc overridefoo {obj args} { if {$args eq "done"} { puts "stop forwarding foo for $obj" set idx [lsearch -exact [my set overrides] $obj] my set overrides [lreplace [my set overrides] $idx $idx] # This doesn't work! What should be here? $obj forward foo {} puts "redispatching foo to native $obj foo" $obj foo $args } else { puts "using override of foo on $obj $args" } } a foo 123 b foo a a foo 234 a foo done ---------- >From what I gather, the intended mechanism for doing this is to use a mixin to intercept the foo method, but a already has a foo method that's being used for other purposes. I suppose I could dynamically create another object (or would it have to be a class?) to use as a mixin, but that seems unnecessarily complex. Is there a better way to accomplish what I'm trying to do? BTW, I'm running xotcl 1.3.6. If I run the above sample 3 times, I get the following error: procedure "foo" has formal parameter "::xotcl::initProcNS" that is not a simple name and the interpreter crashes on the next command. That's probably a bug, but since I'm not at the latest release, I don't know if it's something that's been fixed already. Thanks. 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

Passing a switch non-positional argument
by Kurt Stoll 02 Mar '06

02 Mar '06

I suppose this is a trivial question, but I find this annoying. Is there an easy was of passing a switch non-positional argument to another procedure based upon the value provided to the calling procedure? For example, if both p1 and p2 take a switch non-positional argument -sw, and p2 calls p1, but wants to forward along the state of the -sw parameter, how is that best expressed. The straightforward approach - testing the value of -sw and then using the correct invocation - is ugly, and subject to combinatorial explosion. To avoid the combinatorial problems, and make it a little cleaner, I can collect the options in a list and then make the call (using an eval). This works, and is certainly cleaner, but it still seams that there should be an easier way to pass the value along; passing other options along is simply a matter of calling the option and providing the current value. The example below shows these options: Object obj obj proc p1 {{-sw:switch 0} {-opt 1}} { puts "sw: $sw" puts "opt: $opt" } obj proc p2 {{-sw:switch 0} {-opt 1}} { if { $sw } { my p1 -sw -opt $opt } else { my p1 -opt $opt } } obj proc p3 {{-sw:switch 0} {-opt 1}} { set options [list -opt $opt] if { $sw } { lappend options -sw } eval my p1 $options } Is there a better way to do this? Thanks, Kurt

2 1

RE: [Xotcl] Non-polymorphic methods (long post)
by Kurt Stoll 01 Mar '06

01 Mar '06

Thanks! That helps. And, yes, that was what I had in mind. I had similarly simple examples, but, when I said that I couldn't come up with a simple example, I meant that I couldn't come up with one that had a justifiable need, without getting reasonably complex. I like both of the last two solutions, at least to some extent (the first one is, as you said, "rude"). I had proceeded down an approach similar to the second one, and found that it works. It just seems as if it is a general enough requirement that the language should have built in support for it (and I thought it might already be there and I couldn't find it). But, given the extensible nature of XOTcl (and Tcl, in general), I suppose I can add it to my environment and not worry about the rest of the world. The last solution is one that I had not considered. I find it intriguing and may use it as well. My first objection was that a class proc does not normally have access to instance variables. But, this can be solved by passing in the object itself. This still feels kind of wrong, but I can imagine there may be times when it works. Finally, I did not appreciate all of the complexities that would be involved with eliminating polymorphism. (Of course, I don't really want to eliminate polymorphism; I just want to start the search higher up the tree.) I'm just glad there is someone in a position to appreciate, understand, and plan for these complexities. Thanks again, Kurt Stoll

2 1

Dynamic class change question
by Murr, Florian 01 Mar '06

01 Mar '06

In XOTcl (1.3.8) there seems to be no initialisation of parameters during dynamic class change. See code below: a1 and a2 behave differently. Is this the intended behaviour? - regards, Florian package require XOTcl namespace import xotcl::* eval [string map {INFO {[self] [info level 0] : [my info class] : [my info vars]}} { Class A -parameter { {p 0} } A instproc pp {} { puts "A INFO"; next } Class B -superclass A -parameter { {q 0} } B instproc pp {} { puts "B INFO"; next } }] proc main {} { set strich "--------------------------------------------------------------" puts $strich A create a1 -p a1 a1 class B #a1 init a1 pp #puts "a1 q = [a1 q]" ;# should this be an error? puts $strich A create a2 -p a2 a2 class B a2 q xx a2 pp #puts "a2 q = [a2 q]" puts $strich } main

2 1

Can somebody tell me the creation and destruction processes that go on "behind the scenes" in XOTcl?
by Matthew Dodwell 01 Mar '06

01 Mar '06

Dear All, I've got a question about the behaviour of the destroy / instdest methods; The code below outputs the following: Base init ::MyBase Destroy Base destroy ::MyBase Destroyed ... which is what I would expect. However, if the "next" call in TBase destroy is commented out, the output is: Base init ::MyBase Destroy Base destroy ::MyBase Destroyed Base destroy ::MyBase The extra call to destroy occurs when the command interpreter closes, so must mean that MyBase was not properly destroyed because "next" was not called. This is probably the intended behaviour, but it is difficult to work it out from the examples given in http://media.wu-wien.ac.at/doc/tutorial.html. Can somebody tell me the creation and destruction processes that go on "behind the scenes" in XOTcl? Also, it would be helpful if the differences between XOTcl and other OO languages, say C++, were highlighted as I know I have made assumptions which turn out to be wrong. ------------------------------------------------------------------------ Here is the code: package require XOTcl; namespace import -force xotcl::* package require Tcl 8.4 # define a class Class TBase TBase instproc init {} { my instvar Children Parent puts "Base init [self]" next } TBase instproc destroy {} { my instvar Children Parent puts "Base destroy [self]" next } # do something with it TBase MyBase puts "Destroy" MyBase destroy puts "Destroyed" # code ends Thanks

2 1

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 March 2006