Xotcl February 2006

xotcl@alice.wu.ac.at

13 participants
13 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: [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

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

XOTcl 1.4.0 available
by Gustaf Neumann 18 Feb '06

18 Feb '06

Fellow xotclers, i am glad to annouce the availablity of xotcl 1.4.0. The major changes against 1.3.9 are: * Improved Functionality * new option: ::xotcl::configure softrecreate on|off if softrecreate is set, class relations (superclass, subclass, class, instances) are not affected by a recreate; this allows files with class definitions more easily to reload + easier syntax for providing commands for initializing default values + setting and querying options for ::xotcl::configure simiar to set * Improved Code Quality: + fixed a bug in connection with nonpositional arguments and "args" + fixed a bug with adding on the fly transitive mixin classes + fixed a bug with filter states after next + fixed omitted error message after calling self with unknown subcommands + fixed a bug with variable traces on thread exit (triggered by volatile) + fixed incorrect rpm dependencies + cleaner compile for xotcl for gcc 4.* under linux + don't destroy namespace imported child objects + info children returns true children, not namespace imported objects/classes + unsetting the global variable "cmd" from predefined.xotcl + Upgraded TEA to 3.5 + more regression tests addeed For more details about the changes, please consult the ChangeLog and documentation on www.xotcl.org. The window binaries will follow soon. all the best -gustaf neumann

1 0

instprocs in C
by Aamer Akhter 18 Feb '06

18 Feb '06

Critcl allows us to easily create tcl callable C procs. Is there something similar avaliable for xotcl? Is there any C api documentation? -- Aamer Akhter / aakhter(a)gmail.com

4 5

Non-pos arguments with args
by Kurt Stoll 17 Feb '06

17 Feb '06

I am having difficulty getting non-positional arguments to behave correctly with args. The simple example below shows what I have found. This does not appear to be appropriate behavior. Am I doing something wrong? Object obj obj proc pr1 { {-npos default} args } { puts "npos: $npos" puts "args: $args" } > ## This works: > obj pr1 a npos: default args: a > > ## As does this: > obj pr1 -npos 3 a npos: 3 args: a > > ## But this does not: > obj pr1 -npos 3 npos: 3 args: -npos 3 > > ## I expected args to be {}, but instead it contains the non-positional parameter Thanks for any insight you can provide. -Kurt Stoll

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