xotcl vs incr tcl
in [TCL]
|
Prev: Fedora 12 + Komodo-IDE+debugger=segfault
Next: iso: tcl/tk 8.5.4 or so developers using iwidgets
From: stefan on 10 Mar 2010 05:31 > > you might want to take a look at last year's Tcl conference paper on > > XOTcl. It provides some overview and many pointers:http://nm.wu-wien.ac.at/research/publications/b806.pdf > > Thanks. But the link seems to be broken. for me it works fine, i will send it to you by email. > > in XOTcl jargon, you are looking for "volatile" objects. the volatile > > flag > > (which is passed to the object creation machinery) binds an object to > > a > > Tcl proc scope. once a proc scope is left (and the Tcl callframe is > > cleared), the > > XOTcl object is also "pruned". > > > seehttp://media.wu.ac.at/doc/langRef-xotcl.html#Object-volatile > Yes, I get a "local" object pruned with "volatile", but I do not > succeed in passing its value to the caller. I seems that in XOTcl > returning an "object" from a method, returns the objects's name. Of > course, if the object is already pruned then, this is pretty > worthless. Accessing the "value" of a locally created object in a > method by using the $-operator also gives an error. > > I saw that there are move/copy functions for objects. Maybe using one > of these, would solve the problem. I would need to express things like > "copy the value of this object to the calling object of this method". > > I would like to use methods on objects like this: > - set obj1 [obj2 method ?args?] > where the method "method" called on object "obj2" creates an object > that is bound to the caller object "obj1". No objects created in > "method" should exist after the call, and the object created in > "method" (or the object's value) should be passed to the calling > object "obj1". i am not entirely sure WHY you have this requirement. also, it would be nice to have a more ore less complete code example to comment on. from what i can learn from previous postings, you are trying to do the following (expressed in XOTcl): Class create Complex -parameter {real imag} Complex instproc + {aComplex} { my instvar real imag set resultReal [expr { $real + [$aComplex real] }] set resultImag [expr { $imag + [$aComplex imag] }] set result [Complex new \ -real $resultReal \ -imag $resultImag] return $result } Complex c1 -real 2 -imag 2 Complex c2 -real 2 -imag 2 set c3 [c1 + c2] puts stderr [$c3 imag]; # returns '4' puts stderr [$c3 real]; # returns '4' Now, applied to the example above, when you say: "where the method "method" called on object 'obj2' creates an object that is bound to the caller object 'obj1'." First, it is certainly true that the use of volatile set result [Complex new -volatile \ -real $resultReal \ -imag $resultImag] produces an object (and an object reference) which cannot be used after having returned from the method "+". these are the intended semantics. You want c3 (i.e., the object referenced by the var c3) to be bound (with binding meaning living) to c1 which is the owner/ receiver of the "+" message? Or, is it c2? The most elegant solution (IMHO) for these kind of object-object dependencies are forms of object aggregation: Create the resulting Complex object as nested object of c1: set result [Complex new -childof [self] \ -real $resultReal \ -imag $resultImag] Once c1 gets pruned, its child objects (e.g., the one produced in "+") will be removed too. Dave mentions the idea of binding the resulting object in "+" to the call site of "*" (the scope of the calling method): Class create Complex -parameter {real imag} Complex instproc + {aComplex} { my instvar real imag set resultReal [expr { $real + [$aComplex real] }] set resultImag [expr { $imag + [$aComplex imag] }] set result [uplevel 1 [list Complex new -volatile \ -real $resultReal \ -imag $resultImag]] return $result } Complex instproc foo {} { Complex c1 -real 2 -imag 2 Complex c2 -real 2 -imag 2 set c3 [c1 + c2] puts stderr [$c3 imag]; # returns '4' puts stderr [$c3 real]; # returns '4' return $c3 } set c3 [[Complex new] foo] puts stderr [$c3 imag]; # FAILS! object behind c3 has been pruned after leaving foo() I, personally, consider this a solution which creates hidden (= unwanted) dependencies along the call path between objects due to jumping the callstack by using [uplevel]. Yet, the volatile mechanism of XOTcl is powerful enough to support even such a design decision, if justifiable to you. //stefan
From: dave.joubert on 10 Mar 2010 05:58 On Mar 10, 10:31 am, stefan <stefan.sober...(a)wu.ac.at> wrote: > Now, applied to the example above, when you say: "where the method > "method" called on object 'obj2' creates an object that is bound to > the caller object 'obj1'." > Dave mentions the idea of binding the resulting object in "+" to the > call site of "*" (the scope of the calling method): > > set c3 [[Complex new] foo] > puts stderr [$c3 imag]; # FAILS! object behind c3 has been pruned > after leaving foo() That is precisely my point. Filiberto needs to reconcile the following general facts: 1) the object (by default) is created in the current frame 2) object creation returns a name not an object 3) the name is useless outside the frame that the object exists in These facts have no bearing on whether he should choose to use Xotcl or iTcl, but need to be used when he designs the application; ie 'does a method create a new object and where do I want to use this new object?' Dave
From: dave.joubert on 10 Mar 2010 06:06 On Mar 10, 10:58 am, "dave.joub...(a)googlemail.com" <dave.joub...(a)googlemail.com> wrote: > ... designs the application; ie 'does a method create a new object and where do I want to use this new object?' If you are truly using complex numbers rather just choosing this domain as an example, you may want to create all the objects is a namespace (called for example ::scratchpad), which you can then clean up as required.....
From: fips on 10 Mar 2010 06:26 On 10 Mrz., 10:55, "dave.joub...(a)googlemail.com" <dave.joub...(a)googlemail.com> wrote: > > I would like to use methods on objects like this: > > - set obj1 [obj2 method ?args?] > > where the method "method" called on object "obj2" creates an object > > that is bound to the caller object "obj1". No objects created in > > "method" should exist after the call, and the object created in > > "method" (or the object's value) should be passed to the calling > > object "obj1". > > The way I do it is when I create the new object within the called > method, is I create it in the caller's frame (or toplevel) not the > called frame. > That solves all my problems. (I use iTcl) > > Dave The point is that there is a "simple way" to do this in ITcl and I am searching for an XOTcl equivalent: In ITcl I would do this: public method + { aComplex } { set resultReal [expr { $real + [$aComplex getReal] }] set resultImag [expr { $imag + [$aComplex getImag] }] set result [Complex #auto $resultReal $resultImag] return $result } The line "set result [Complex #auto $resultReal $resultImag]" creates exactly the kind of object I need (specifier #auto) and then "return $result" returns the value of the object. This value can then be used by the method's caller.
From: Koen Danckaert on 10 Mar 2010 06:50
fips wrote: > On 10 Mrz., 10:55, "dave.joub...(a)googlemail.com" > <dave.joub...(a)googlemail.com> wrote: >>> I would like to use methods on objects like this: >>> - set obj1 [obj2 method ?args?] >>> where the method "method" called on object "obj2" creates an object >>> that is bound to the caller object "obj1". No objects created in >>> "method" should exist after the call, and the object created in >>> "method" (or the object's value) should be passed to the calling >>> object "obj1". >> The way I do it is when I create the new object within the called >> method, is I create it in the caller's frame (or toplevel) not the >> called frame. >> That solves all my problems. (I use iTcl) >> >> Dave > > The point is that there is a "simple way" to do this in ITcl and I am > searching for an XOTcl equivalent: > In ITcl I would do this: > > public method + { aComplex } { > > set resultReal [expr { $real + [$aComplex getReal] }] > set resultImag [expr { $imag + [$aComplex getImag] }] > set result [Complex #auto $resultReal $resultImag] > return $result > } > > The line "set result [Complex #auto $resultReal $resultImag]" creates > exactly the kind of object I need (specifier #auto) and then "return > $result" returns the value of the object. This value can then be used > by the method's caller. You are confusing things here. Both IncrTcl and XOTcl always refer to objects by their name and not by their value. The "#auto" specifier simply selects a unique name. It has nothing to do with automatic cleanup. In XOTcl you can use the [new] method to achieve what you want: set result [Complex new $resultReal $resultImag] return $result --Koen |