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 06:55
> 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.

then go with new() in XOTcl ... new creates an auto-named object,
here
in the Tcl top-level namespace "::".

set result [Complex new \
-real $resultReal \
-imag $resultImag]

That is, the resulting will not be bound in its lifespan to the
callframe of "+".
If you want such a binding (for whatever reasons), my previous post
contains
some pointers: a) object nesting b) an XOTcl'ish [uplevel] variant as
hinted
by Dave.

//stefan
From: Larry W. Virden on 10 Mar 2010 06:58
On Mar 9, 12:28 pm, fips <filiberto.silves...(a)hotmail.de> wrote:

>
> (2) proposal for inclusion in Tcl core: "XOTcl" has been proposed for
> inclusion in the Tcl core.
>      Does anybody know whether there are similar proposals for "Incr
> Tcl"?

Not only similar proposals - but actual implementation. Tcl 8.6 has
incr tcl included as a package.

As for amount of code, I've generally seen incr tcl code written in
the community rather than xotcl.
From: dave.joubert on 10 Mar 2010 07:22
On Mar 10, 11:26 am, fips <filiberto.silves...(a)hotmail.de> wrote:
<snip>
>
> 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.

Sorry I think one of us is mistaken .....

Koen Dankaert wrote:
>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.

I do not know how many times we have to stress 'return by name not
return by value.

Here is a sample script:
# Based on Complex.itcl by Dr. I. for CS 101 during Fall, 2001
# This script defines a simple Complex number class
class Complex {
public constructor {r i} { setReal $r ; setImag $i }
public destructor { }

public method setReal {r} { set real $r }
public method getReal {} { return $real }

public method setImag {i} { set imag $i }
public method getImag {} { return $imag }

public method showComplex {} { puts -nonewline stdout "$real + $imag
i" ; flush stdout }

public method + { aComplex } {
set resultReal [expr { $real + [$aComplex getReal] }]
set resultImag [expr { $imag + [$aComplex getImag] }]
set result [Complex #auto $resultReal $resultImag]
return $result
}
private variable real; private variable imag;
}

Complex c1 2 2
Complex c2 2 2
set c3 [c1 + c2]

puts "$c3"

then (which is rubbish)
c3 showComplex
invalid command name "c3"
while executing
"c3 showComplex"
(file "xx.test.tcl" line 33)

or
$c3 showComplex
invalid command name "complex0"
while executing
"$c3 showComplex"

So:
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

If you experience is different, then show us all the code...
Dave



From: fips on 10 Mar 2010 07:43
On 10 Mrz., 11:31, stefan <stefan.sober...(a)wu.ac.at> wrote:
> > > 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

Ok here is the complete code example:


package require XOTcl
namespace import xotcl::*

# *************************************
# Declare.
# *************************************

# Class.
Class Complex

# Fields.
Complex set real 0
Complex set imag 0

# Constructor.
Complex instproc init { { number1 0 } { number2 0 } } {

my instvar real imag
set real $number1
set imag $number2
}

# Method "add".
Complex instproc add { aComplex } {

my instvar real imag
set resultReal [expr { $real + [$aComplex set real] }]
set resultImag [expr { $imag + [$aComplex set imag] }]
Complex result $resultReal $resultImag
}

# Method "assign".
Complex instproc assign { aComplex } {

my instvar real imag
set real [$aComplex set real]
set imag [$aComplex set imag]
}

# Method "toString".
Complex instproc toString {} {

my instvar real imag
set stringRep "[self]> real: $real, imag: $imag"
return $stringRep
}

# *************************************
# Use.
# *************************************

Complex c1 1 3
Complex c2 -2 10
Complex c3

puts "instances: [Complex info instances]"

puts [c1 toString]
puts [c2 toString]
puts [c3 toString]

c3 assign [c1 add c2]

puts [c1 toString]
puts [c2 toString]
puts [c3 toString]

c1 destroy
c2 destroy
c3 destroy

puts "instances: [Complex info instances]"
# "::result" created in "add" still exists here


From: fips on 10 Mar 2010 07:44
On 10 Mrz., 12:06, "dave.joub...(a)googlemail.com"
<dave.joub...(a)googlemail.com> wrote:
> 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.....


The use of complex numbers is just an example.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Fedora 12 + Komodo-IDE+debugger=segfault
Next: iso: tcl/tk 8.5.4 or so developers using iwidgets