Xotcl

xotcl@alice.wu.ac.at

2 participants
653 discussions

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

Non-polymorphic methods (long post)
by Kurt Stoll 26 Feb '06

26 Feb '06

(Sorry for the long post) Well, I've perused the archives and can't find anything on this topic. Nor can I find it in the tutorial or reference guide. So, I must conclude that I am missing something. Either this is obvious, and everyone has already figured this out. Or, there is no real need for this type of a construct and I'm thinking about this incorrectly. Many OO languages provide a means to make some methods be polymorphic and some not. For example, C++ uses the virtual keyword to make a function polymorphic; otherwise it's not. XOTcl on the other hand appears to only support polymorphic methods. A call to a method from a given level of the hierarchy starts from the class of the calling object and works its way up (assuming next is used). For example, a class Base provides an interface, then Sub1 and Sub2 (both subclasses of Base) provide a thin veneer on that interface. The methods have the same name. And, in some cases, they rely on Base to provide some of the functionality. But, Base provides its own functionality by composing some of its own methods into more complex methods. Now, when a method from Sub1 is called, it calls that method in Base, and Base then calls another method within Base - except that when it makes this call, it gets the version from Sub1. In some cases, this may be the correct approach. But, there are certainly cases where this is not desired. We could try pushing some of the implementation from Base into Sub1, but Sub2 wants similar functionality. This would mean duplicating code. Another approach might be delegation, instead of inheritance. This would work, but, all three classes (Base, Sub1, and Sub2) have instances that share a common interface. Now, to add a new method to that interface requires changing two different class hierarchies. Again, this would work, but it just doesn't feel right. I realize that this is a fairly abstract presentation of the issue. I have attempted to come up with a simple example - for example, geometric figures, with the base class rooting the centroid at the origin to provide easy rotations. But, even here, this gets complicated. and I'm afraid that the discussion will veer off to trying to solve some particular quirk of the example. But, I have run into this issue several times, and have found it frustrating. The only solution that I have found is to provide both an "internal" implementation and a public implementation of some methods (for example, prefix the internal method name with an underscore). Then, the implementation can decide whether it is wants to use the polymorphic method or the non-polymorphic version. But, this doesn't really solve the problem - I still have to be careful not to override the internal version (because, I don't really have a non-polymorphic method - I just have some conventions to avoid the polymorphism). This could get truly complicated with a large class hierarchy, but none of my constructs have reached the point (yet). Actually, I can imagine a second potential solution, although I have not tried it. I think it would work, but would be very ugly. Nevertheless, I bring it up because I believe it might form the basis of what I think would be an elegant solution to this problem. I could temporarily change the class of the object to reflect where I want the method search to begin from. Then, change it back when the method returns. Artificially changing the class of an object makes me cringe - I don't really like this approach. But, it seems to me that if XOTcl can provide a way to force the method search to begin at a particular class, this would fix the problem. Maybe something like: [self as class] <method> <args>. In fact, I think I can implement this as an Object method - simply copy the class, change it, make the call, destroy the copy, and return the result. I think this would work, and may try it. But, I still feel like I must be missing something. Any thoughts would be appreciated. Thanks, Kurt Stoll

2 1

AW: Re: [Xotcl] Using instforward to wrap other packages
by mail＠xdobry.de 24 Feb '06

24 Feb '06

Hi! Learnable lazy wrapper per unknown mechanism. Should one do such magic thinks? package require XOTcl namespace import ::xotcl::* package require struct::queue Class Queue -parameter {{queue [self]::queue}} Queue instproc init {} { ::struct::queue [my queue] } Queue instproc destroy {} { [self]::queue destroy next } Queue instproc unknown {args} { # some debbug puts "learning [lindex $args 0]" Queue instforward [lindex $args 0] {%my queue} %proc # maybe learn only if that calls success eval [self]::queue $args } Testing (bin) 31 % Queue create q1 ::q1 (bin) 32 % q1 put 32 learning put (bin) 33 % q1 put 43 (bin) 34 % q1 get learning get 32 (bin) 35 % q1 get 43 (bin) 35 % Artur

2 1

xotcl 1.4.0 and windows binaries
by Gustaf Neumann 23 Feb '06

23 Feb '06

Dear Tcl Community, Thanks to Uwe, the windows binaries are now on www.xotcl.org. This is most probably the last time that we provide tcl8.3* binaries. Tcl 8.4 is out since 2002, i think there is little reason to use tcl 8.3 now. The incompatiblity is for the tcl scripts only, the c code does not depend on tcl 8.4. For comparisons, we are moving towards using "eq" and "ne" where appropriate. If you want to normalize comparisons in older scripts as well, drop me a note, i have a script for doing these changes... best regards -gustaf neumann

1 0

Using instforward to wrap other packages
by Michael Schlenker 23 Feb '06

23 Feb '06

Hi all, i tried wrapping the ::struct::queue datastructure from Tcllib with a simple XOTcl wrapper, but I'm unsure if there is a better way to setup the instforwarder, it looks too complex to be really the best solution. package require XOTcl namespace import ::xotcl::* package require struct::queue Class Queue Queue instproc init {args} { next ::struct::queue [self]::queue } Queue instforward clear eval {[self]::queue} clear Queue instforward get eval {[self]::queue} get Queue instforward peek eval {[self]::queue} peek Queue instforward put eval {[self]::queue} put Queue instforward unget eval {[self]::queue} unget Queue instforward size eval {[self]::queue} size Queue instproc destroy {args} { queue destroy next } Any hints on how to do this in a nicer way? Michael

2 1

← Newer
1
...
27
28
29
30
31
32
33
...
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