Hello to all,

I am using Tcl in my company. We are planning to use "XOTcl" or "Incr
Tcl" as OO-extension for Tcl. But, at the moment, we do not know which
one to go for.

There are still some open questions, maybe someone in this ng is able
to anwer to:

(1) stability: I have heard that "Incr Tcl" had some problems with
memory leaks in the past.
     So I wonder if this is still true. Does anybody know if "XOTcl"
has similar problems?

(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"?

(3) automatic objects:
     In Incr Tcl, objects can be created in a method in a way that the
created object is deleted by the runtime
     after method completion.
     The following code fragement shows an example:

      public method + { aComplex } {

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

      It shows a hypothetical operator overloading for "+" in order to
add two complex numbers.
      The class is named "Complex" and the object fields "real" and
"image" would contain the data.
      Here the object created with the specifier "#auto" is deleted
after the value of the object is passes by "return"

      The following code fragement shows similar code for XOTcl:

      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
      }

      The problem here with the object "result" is that it is still
there after method conclusion.
      Creating the object with the "-volatile" switch does not help,
because then the object is deleted but when
      trying to access the object (or the object's value) from the
caller the runtime generates an error.

Any suggestion is really appreciated. Thanks

On Mar 9, 5:28=A0pm, fips <filiberto.silves...@hotmail.de> wrote:
> Hello to all,
>
> I am using Tcl in my company. We are planning to use "XOTcl" or "Incr
> Tcl" as OO-extension for Tcl. But, at the moment, we do not know which
> one to go for.
>
> There are still some open questions, maybe someone in this ng is able
> to anwer to:
>
> (1) stability: I have heard that "Incr Tcl" had some problems with
> memory leaks in the past.
> =A0 =A0 =A0So I wonder if this is still true. Does anybody know if "XOTcl=
"
> has similar problems?
>
> (2) proposal for inclusion in Tcl core: "XOTcl" has been proposed for
> inclusion in the Tcl core.
> =A0 =A0 =A0Does anybody know whether there are similar proposals for "Inc=
r
> Tcl"?

In view of the fact that tclOO is 'core', and the latest version of
iTcl has been re-written to use this, this is a plus for iTcl.

>
> (3) automatic objects:
> =A0 =A0 =A0In Incr Tcl, objects can be created in a method in a way that =
the
> created object is deleted by the runtime
> =A0 =A0 =A0after method completion.
> =A0 =A0 =A0The following code fragement shows an example:
>
> =A0 =A0 =A0 public method + { aComplex } {
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultReal [expr { $real + [$aComplex=
 getReal] }]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultImag [expr { $imag + [$aComplex=
 getImag] }]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set result [Complex #auto $resultReal $re=
sultImag]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return $result
> =A0 =A0 =A0 }
>
Cannot talk about xotcl, but I feel you are gambling here.
Normally the create process creates an object and returns the name of
the new object.

Dave

Hello,
just my 0.02.

IncrTcl implements the C++ model of OO. This could mean that people
coming from other languages (C++, Delphi, Java, C#) run a good chance
of finding it familiar. For me at least (coming from C++ at the time)
this was a very attractive feature.

Over the years I have moved over to XOTcl - it's so much more
powerful. Things are possible which I wouldn't have dreamed of while
thinking inside the limits/possibilities of C++ (or similar OO
systems). mixins come to mind - on the class level or for individual
objects - features like this combined with the dynamic nature of Tcl
make for phantastic possibilites.
Of course, as in real life this power has its price: complexity.
Whenever I started a new (XOTcl based) project I found myself sooner
or later coming here calling for help - usually with success, though,
so I do not consider this a show stopper.
I can think of one scenario where this complexity could present a
problem: A team of programmers where you have one guru which really
groks XOTcl, delights in the possibilities it offers, creates
something fantastic - and then leaves. If you don't have an excellent
_structural_ documentation of the system the rest of the team may have
a hard time. This may or may not be a concern for you.

As for your specific questions they don't ring any bell with me:
1) Stability: I never had any problem with either of the two - but
then my systems may have been a lot smaller than what you are doing.
2) Inclusion in the core: If you are on a system which is supported by
ActiveState both are included in the distro.
3) Automatic objects: I don't remember if I ever used them in ITcl and
I know I never missed it in XOTcl - which should not imply that it is
not possible there, I just never cared.

Ok, here you go. Best regards
Helmut Giese

On Tue, 9 Mar 2010 09:28:35 -0800 (PST), fips
<filiberto.silvestri@hotmail.de> wrote:

>Hello to all,
>
>I am using Tcl in my company. We are planning to use "XOTcl" or "Incr
>Tcl" as OO-extension for Tcl. But, at the moment, we do not know which
>one to go for.
>
>There are still some open questions, maybe someone in this ng is able
>to anwer to:
>
>(1) stability: I have heard that "Incr Tcl" had some problems with
>memory leaks in the past.
>     So I wonder if this is still true. Does anybody know if "XOTcl"
>has similar problems?
>
>(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"?
>
>(3) automatic objects:
>     In Incr Tcl, objects can be created in a method in a way that the
>created object is deleted by the runtime
>     after method completion.
>     The following code fragement shows an example:
>
>      public method + { aComplex } {
>
>		set resultReal [expr { $real + [$aComplex getReal] }]
>		set resultImag [expr { $imag + [$aComplex getImag] }]
>		set result [Complex #auto $resultReal $resultImag]
>		return $result
>      }
>
>      It shows a hypothetical operator overloading for "+" in order to
>add two complex numbers.
>      The class is named "Complex" and the object fields "real" and
>"image" would contain the data.
>      Here the object created with the specifier "#auto" is deleted
>after the value of the object is passes by "return"
>
>      The following code fragement shows similar code for XOTcl:
>
>      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
>      }
>
>      The problem here with the object "result" is that it is still
>there after method conclusion.
>      Creating the object with the "-volatile" switch does not help,
>because then the object is deleted but when
>      trying to access the object (or the object's value) from the
>caller the runtime generates an error.
>
>Any suggestion is really appreciated. Thanks
>

On Mar 9, 11:55=A0am, "dave.joub...@googlemail.com"
<dave.joub...@googlemail.com> wrote:
> On Mar 9, 5:28=A0pm, fips <filiberto.silves...@hotmail.de> wrote:
>
>
>
>
>
> > Hello to all,
>
> > I am using Tcl in my company. We are planning to use "XOTcl" or "Incr
> > Tcl" as OO-extension for Tcl. But, at the moment, we do not know which
> > one to go for.
>
> > There are still some open questions, maybe someone in this ng is able
> > to anwer to:
>
> > (1) stability: I have heard that "Incr Tcl" had some problems with
> > memory leaks in the past.
> > =A0 =A0 =A0So I wonder if this is still true. Does anybody know if "XOT=
cl"
> > has similar problems?
>
> > (2) proposal for inclusion in Tcl core: "XOTcl" has been proposed for
> > inclusion in the Tcl core.
> > =A0 =A0 =A0Does anybody know whether there are similar proposals for "I=
ncr
> > Tcl"?
>
> In view of the fact that tclOO is 'core', and the latest version of
> iTcl has been re-written to use this, this is a plus for iTcl.
>
>
>
> > (3) automatic objects:
> > =A0 =A0 =A0In Incr Tcl, objects can be created in a method in a way tha=
t the
> > created object is deleted by the runtime
> > =A0 =A0 =A0after method completion.
> > =A0 =A0 =A0The following code fragement shows an example:
>
> > =A0 =A0 =A0 public method + { aComplex } {
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultReal [expr { $real + [$aCompl=
ex getReal] }]
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultImag [expr { $imag + [$aCompl=
ex getImag] }]
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set result [Complex #auto $resultReal $=
resultImag]
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return $result
> > =A0 =A0 =A0 }
>
> Cannot talk about xotcl, but I feel you are gambling here.
> Normally the create process creates an object and returns the name of
> the new object.
>
> Dave

My advice is to look for production code written in each object
system. I haven't found much ITcl code, but there is a lot of XOTcl
code. I don't understand either enough to comment, but more working
production code implies more problems have been worked out and more
examples exist to explain how the system works.

Both systems have a sound theoretical basis, one from C++ and the
other from CLOS (Common Lisp Object System).

On 9 Mrz., 20:55, "dave.joub...@googlemail.com"
<dave.joub...@googlemail.com> wrote:
> On Mar 9, 5:28=A0pm, fips <filiberto.silves...@hotmail.de> wrote:
>

>
> In view of the fact that tclOO is 'core', and the latest version of
> iTcl has been re-written to use this, this is a plus for iTcl.
>

Yes, thanks for this info. I did not consider in detail all available
OO-extensions. As XOTcl and ITcl are supported by Eclipse plugins
those seemed "mainstream" to me. So I considered these.

>
> > (3) automatic objects:
> > =A0 =A0 =A0In Incr Tcl, objects can be created in a method in a way tha=
t the
> > created object is deleted by the runtime
> > =A0 =A0 =A0after method completion.
> > =A0 =A0 =A0The following code fragement shows an example:
>
> > =A0 =A0 =A0 public method + { aComplex } {
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultReal [expr { $real + [$aCompl=
ex getReal] }]
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultImag [expr { $imag + [$aCompl=
ex getImag] }]
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set result [Complex #auto $resultReal $=
resultImag]
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return $result
> > =A0 =A0 =A0 }
>
> Cannot talk about xotcl, but I feel you are gambling here.
> Normally the create process creates an object and returns the name of
> the new object.
>
> Dave

The point is that I would like to create objects in methods without
creating "garbage". So I looked for a way to do this in XOTcl by I
haven't succeeded so far. Of course it would be possible to implement
some garbage collection using naming conventions for the "temporary
objects" created in methods, but this adds complexity I would like to
avoid if possible.

On 9 Mrz., 22:16, Helmut Giese <hgi...@ratiosoft.com> wrote:
> Hello,
> just my 0.02.
>
> IncrTcl implements the C++ model of OO. This could mean that people
> coming from other languages (C++, Delphi, Java, C#) run a good chance
> of finding it familiar. For me at least (coming from C++ at the time)
> this was a very attractive feature.
>

Thanks for your detailed answer.
Yes, ITcl is very appealing to those having a strong OO-background in
languages like C++/Java/C#.

> Over the years I have moved over to XOTcl - it's so much more
> powerful. Things are possible which I wouldn't have dreamed of while
> thinking inside the limits/possibilities of C++ (or similar OO
> systems). mixins come to mind - on the class level or for individual
> objects - features like this combined with the dynamic nature of Tcl
> make for phantastic possibilites.

Certainly, XOTcl is more "dynamic" than ITcl. And the question I posed
to myself is: will we ever need all this?
At the moment, "rewriting" a method in a class for bufix purposes is
an issue.

> Of course, as in real life this power has its price: complexity.
> Whenever I started a new (XOTcl based) project I found myself sooner
> or later coming here calling for help - usually with success, though,
> so I do not consider this a show stopper.

Yes, complexity is always a point to consider. The main purpose in
"going OO" is to gain expressive power, not code obfuscation...

> I can think of one scenario where this complexity could present a
> problem: A team of programmers where you have one guru which really
> groks XOTcl, delights in the possibilities it offers, creates
> something fantastic - and then leaves. If you don't have an excellent
> _structural_ documentation of the system the rest of the team may have
> a hard time. This may or may not be a concern for you.

At the momement there is no guru, only programmers :-) But I agree
that code using dynamic features would probably be more complex to
understand if to well documented.

>
> As for your specific questions they don't ring any bell with me:
> 1) Stability: I never had any problem with either of the two - but
> then my systems may have been a lot smaller than what you are doing.
> 2) Inclusion in the core: If you are on a system which is supported by
> ActiveState both are included in the distro.

Sadly, there is no binary distribution that fits exactly our needs,
because we need to be heavily "cross-platform". So taking the sources
and building our own distributions on the various platforms is the
only way to go for us.

> 3) Automatic objects: I don't remember if I ever used them in ITcl and
> I know I never missed it in XOTcl - which should not imply that it is
> not possible there, I just never cared.
>
> Ok, here you go. Best regards
> Helmut Giese
>
> On Tue, 9 Mar 2010 09:28:35 -0800 (PST), fips
>

Ok, thanks.

On 10 Mrz., 01:57, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
> On Mar 9, 11:55=A0am, "dave.joub...@googlemail.com"
>
>
>
> <dave.joub...@googlemail.com> wrote:
> > On Mar 9, 5:28=A0pm, fips <filiberto.silves...@hotmail.de> wrote:
>
> > > Hello to all,
>
> > > I am using Tcl in my company. We are planning to use "XOTcl" or "Incr
> > > Tcl" as OO-extension for Tcl. But, at the moment, we do not know whic=
h
> > > one to go for.
>
> > > There are still some open questions, maybe someone in this ng is able
> > > to anwer to:
>
> > > (1) stability: I have heard that "Incr Tcl" had some problems with
> > > memory leaks in the past.
> > > =A0 =A0 =A0So I wonder if this is still true. Does anybody know if "X=
OTcl"
> > > has similar problems?
>
> > > (2) proposal for inclusion in Tcl core: "XOTcl" has been proposed for
> > > inclusion in the Tcl core.
> > > =A0 =A0 =A0Does anybody know whether there are similar proposals for =
"Incr
> > > Tcl"?
>
> > In view of the fact that tclOO is 'core', and the latest version of
> > iTcl has been re-written to use this, this is a plus for iTcl.
>
> > > (3) automatic objects:
> > > =A0 =A0 =A0In Incr Tcl, objects can be created in a method in a way t=
hat the
> > > created object is deleted by the runtime
> > > =A0 =A0 =A0after method completion.
> > > =A0 =A0 =A0The following code fragement shows an example:
>
> > > =A0 =A0 =A0 public method + { aComplex } {
>
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultReal [expr { $real + [$aCom=
plex getReal] }]
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultImag [expr { $imag + [$aCom=
plex getImag] }]
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set result [Complex #auto $resultReal=
 $resultImag]
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return $result
> > > =A0 =A0 =A0 }
>
> > Cannot talk about xotcl, but I feel you are gambling here.
> > Normally the create process creates an object and returns the name of
> > the new object.
>
> > Dave
>
> My advice is to look for production code written in each object
> system. I haven't found much ITcl code, but there is a lot of XOTcl
> code. I don't understand either enough to comment, but more working
> production code implies more problems have been worked out and more
> examples exist to explain how the system works.
>
> Both systems have a sound theoretical basis, one from C++ and the
> other from CLOS (Common Lisp Object System).

Yes, I also noticed that there is more XOTcl code available than for
ITcl. I will have a walk through some of this code.

filiberto,

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

> > > (3) automatic objects:
> > > =A0 =A0 =A0In Incr Tcl, objects can be created in a method in a way t=
hat the
> > > created object is deleted by the runtime
> > > =A0 =A0 =A0after method completion.
> > > =A0 =A0 =A0The following code fragement shows an example:
>
> > > =A0 =A0 =A0 public method + { aComplex } {
>
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultReal [expr { $real + [$aCom=
plex getReal] }]
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultImag [expr { $imag + [$aCom=
plex getImag] }]
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set result [Complex #auto $resultReal=
 $resultImag]
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return $result
> > > =A0 =A0 =A0 }
>
> > Cannot talk about xotcl, but I feel you are gambling here.
> > Normally the create process creates an object and returns the name of
> > the new object.
>
> > Dave
>
> The point is that I would like to create objects in methods without
> creating "garbage". So I looked for a way to do this in XOTcl by I
> haven't succeeded so far. Of course it would be possible to implement
> some garbage collection using naming conventions for the "temporary
> objects" created in methods, but this adds complexity I would like to
> avoid if possible.

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".

see http://media.wu.ac.at/doc/langRef-xotcl.html#Object-volatile

best
//stefan

On 10 Mrz., 10:03, stefan <stefan.sober...@wu.ac.at> wrote:
> filiberto,
>
> 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.

>
> 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
>
> best
> //stefan

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

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

On Mar 10, 10:31=A0am, stefan <stefan.sober...@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

On Mar 10, 10:58=A0am, "dave.joub...@googlemail.com"
<dave.joub...@googlemail.com> wrote:
> ... designs the application; ie 'does a method create a new object and wh=
ere 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.....

On 10 Mrz., 10:55, "dave.joub...@googlemail.com"
<dave.joub...@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.

fips wrote:
> On 10 Mrz., 10:55, "dave.joub...@googlemail.com"
> <dave.joub...@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

> 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

On Mar 9, 12:28=A0pm, fips <filiberto.silves...@hotmail.de> wrote:

>
> (2) proposal for inclusion in Tcl core: "XOTcl" has been proposed for
> inclusion in the Tcl core.
> =A0 =A0 =A0Does anybody know whether there are similar proposals for "Inc=
r
> 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.

On Mar 10, 11:26=A0am, fips <filiberto.silves...@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:
>
> =A0 =A0 public method + { aComplex } {
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultReal [expr { $real + [$aComplex=
 getReal] }]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set resultImag [expr { $imag + [$aComplex=
 getImag] }]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 set result [Complex #auto $resultReal $re=
sultImag]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return $result
> =A0 =A0 }
>
> 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 obje=
cts by their name and not by their value. The "#auto" specifier simply sele=
cts 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

On 10 Mrz., 11:31, stefan <stefan.sober...@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} {
> =A0 my instvar real imag
> =A0 set resultReal [expr { $real + [$aComplex real] }]
> =A0 set resultImag [expr { $imag + [$aComplex imag] }]
> =A0 set result [Complex new \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -real $resultReal \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -imag $resultImag]
> =A0 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 \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -real $resultReal \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -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] \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -real $resultReal \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -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} {
> =A0 my instvar real imag
> =A0 set resultReal [expr { $real + [$aComplex real] }]
> =A0 set resultImag [expr { $imag + [$aComplex imag] }]
> =A0 set result [uplevel 1 [list Complex new -volatile \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-real $resultR=
eal \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-imag $resultI=
mag]]
> =A0 return $result
>
> }
>
> Complex instproc foo {} {
> =A0 Complex c1 -real 2 -imag 2
> =A0 Complex c2 -real 2 -imag 2
> =A0 set c3 [c1 + c2]
> =A0 puts stderr [$c3 imag]; # returns '4'
> =A0 puts stderr [$c3 real]; # returns '4'
> =A0 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 (=3D
> 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

On 10 Mrz., 12:06, "dave.joub...@googlemail.com"
<dave.joub...@googlemail.com> wrote:
> On Mar 10, 10:58=A0am, "dave.joub...@googlemail.com"
>
> <dave.joub...@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.

On 10 Mrz., 12:50, Koen Danckaert <k...@spam.spam> wrote:
> fips wrote:
> > On 10 Mrz., 10:55, "dave.joub...@googlemail.com"
> > <dave.joub...@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:
>
> > =A0 =A0 public method + { aComplex } {
>
> > =A0 =A0 =A0 =A0 =A0 =A0set resultReal [expr { $real + [$aComplex getRea=
l] }]
> > =A0 =A0 =A0 =A0 =A0 =A0set resultImag [expr { $imag + [$aComplex getIma=
g] }]
> > =A0 =A0 =A0 =A0 =A0 =A0set result [Complex #auto $resultReal $resultIma=
g]
> > =A0 =A0 =A0 =A0 =A0 =A0return $result
> > =A0 =A0 }
>
> > 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 obj=
ects by their name and not by their value. The "#auto" specifier simply sel=
ects a unique name. It has nothing to do with automatic cleanup.
>
> In XOTcl you can use the [new] method to achieve what you want:
>
> =A0 set result [Complex new $resultReal $resultImag]
> =A0 return $result
>
> --Koen

Ok, maybe you are right on the meaning of "#auto". That would mean
that the mentioned "deallocation-passing" problem would also exist
with ITcl.

On Mar 10, 12:44=A0pm, fips <filiberto.silves...@hotmail.de> wrote:

>
> The use of complex numbers is just an example.

You also wrote earlier:
> The point is that I would like to create objects in methods without creat=
ing "garbage".

OK, but as a general rule, if you are going to have methods that
create objects, then you should create the objects somewhere
predictable (where you know that you can get at them (irrespective of
which object framework you end up using)).

A) creating them in the called frame in useless, because as you can
see, they 'disappear'
B) creating them in the caller [uplevel] frame forces you to remember
to in turn pass them back up if the call is indirect
C) creating them in the global namespace is messy

Dave

On 9 Mar, 17:28, fips <filiberto.silves...@hotmail.de> wrote:
> The problem here with the object "result" is that it is still
> there after method conclusion.

Yes. The issue is simply that Tcl doesn't do Garbage Collection of
commands[*], and Tcl objects are always commands. There *are* several
ways to fake it. Nasty ways. (For example, the -volatile option you
mention is using an unset trace on a local variable. It's fine if
you're going to follow the RAII model, but there are other models -
[uplevel] is a great thing - that feel even more natural in Tcl.)

Donal.
[* Strictly, it doesn't do that for values either, but Tcl's value
system doesn't need it and so reference counting - which is used -
works just fine. ]

On 10 Mar, 08:26, fips <filiberto.silves...@hotmail.de> wrote:
> Certainly, XOTcl is more "dynamic" than ITcl. And the question I posed
> to myself is: will we ever need all this?

One advantage of going to a more powerful system is that it allows
features that *are* interesting to be written more simply. For
example, object serialization (and, more to the point,
deserialization) is something that's simple enough in a system with
XOTcl's power, but where Itcl's restrictions become more of an issue.
It's only an example, of course, but even so.

For my money, I'd say that you should go with the one that feels more
natural to you. Trying both out won't take very long and both are well-
supported with communities of users.

Donal.

On 10 Mrz., 14:30, "Donal K. Fellows"
<donal.k.fell...@manchester.ac.uk> wrote:
> On 9 Mar, 17:28, fips <filiberto.silves...@hotmail.de> wrote:
>
> > The problem here with the object "result" is that it is still
> > there after method conclusion.
>
> Yes. The issue is simply that Tcl doesn't do Garbage Collection of
> commands[*], and Tcl objects are always commands. There *are* several
> ways to fake it. Nasty ways. (For example, the -volatile option you
> mention is using an unset trace on a local variable. It's fine if
> you're going to follow the RAII model, but there are other models -
> [uplevel] is a great thing - that feel even more natural in Tcl.)
>
> Donal.
> [* Strictly, it doesn't do that for values either, but Tcl's value
> system doesn't need it and so reference counting - which is used -
> works just fine. ]

Maybe I found a solution to the object deletion/passing problem that
would be quite satisfactory for me.
The idea is, as proposed by some in the ng here, to "store" objects
created by methods where they can easily be found and deleted as
needed. I thought about storing them as child objects in their
classes.
The following code fragment shows this:

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

	my instvar real imag
	set resultReal [expr { $real + [$aComplex set real] }]
	set resultImag [expr { $imag + [$aComplex set imag] }]
	eval Complex new -childof Complex $resultReal $resultImag
}

The method "add" is rewritten with the following changes:
- the "new" function assigns a unique name to the object
- the object is stored as child of its class

A garbage collector functions which iterates through classes and
cleans them up could be as follows:

# Garbage collector.
# Deletes temporary objects created in method calls.
proc gc {} {

	# Iterate on all classes.
	foreach class_ [Class info instances] {

		# Skip system classes.
		if { $class_ == "::__unknown" || [string first "::xotcl" $class_] !=
-1 } {
			continue
		}

		# Cleaup user defined class by deleting all its children.
		foreach child [$class_ info children] {
			$child destroy
		}
	}
}

On Mar 10, 2:05=A0pm, fips <filiberto.silves...@hotmail.de> wrote:

> The idea is, as proposed by some in the ng here, to "store" objects
> created by methods where they can easily be found and deleted as
> needed.
Good
> I thought about storing them as child objects in their classes.

Will your proposed solution allow you to write code that looks like
this:

set c1 [Complex 2  2]
set c2 [Complex 2  2]
set c3 [$c1 + $c2]
set c4 [$c2 + [$c3 + $c1]]
set c5 [[$c1 + $c4] + $c2]

If it does not, why should you (as a programmer (not you as a
designer)) have to know that some objects are not 'equal citizens' ?

(Note: having to sugar each variable with a consistent namespace would
not fundamentally change the question, and can in fact improve code
readability.)

Dave

On 10 Mrz., 16:09, "dave.joub...@googlemail.com"
<dave.joub...@googlemail.com> wrote:
> On Mar 10, 2:05=A0pm, fips <filiberto.silves...@hotmail.de> wrote:
>
>
>
> > The idea is, as proposed by some in the ng here, to "store" objects
> > created by methods where they can easily be found and deleted as
> > needed.
> Good
> > I thought about storing them as child objects in their classes.
>
> Will your proposed solution allow you to write code that looks like
> this:
>
> set c1 [Complex 2 =A02]
> set c2 [Complex 2 =A02]
> set c3 [$c1 + $c2]
> set c4 [$c2 + [$c3 + $c1]]
> set c5 [[$c1 + $c4] + $c2]
>
> If it does not, why should you (as a programmer (not you as a
> designer)) have to know that some objects are not 'equal citizens' ?
>
> (Note: having to sugar each variable with a consistent namespace would
> not fundamentally change the question, and can in fact improve code
> readability.)
>
> Dave

The code will be used like this:

Complex c1 1 3
Complex c2 -2 10
Complex c3 4.5 13.6
Complex c4

c4 assign [[c1 sub c2] add [c3 addNumber 100]]

c1 destroy
c2 destroy
c3 destroy
c4 destroy

gc

Here, I supposed to have methods similar to "add":
- "sub" to subtract complex numbers
- "addNumber" to add a complex number to a scalar number
- "assign" to assign the value of a complex number to another complex
number
The whole complex number thing is only an example.

As I like symmetries in code, I'd like to see the "destroys" in equal
number to the "inits" for each class. Maybe this is due to my C/C++
background...

Anyway, to delete the "temporaries" created by the methods, calling a
garbage collector method like "gc" will free the memory not needed
anymore.

The call to "gc" does not necessarily have to occur at the "end of a
program". Think of a server program intended to run for an indefinite
period of time. If this program creates "temporaries" continuously,
without garbage collection there will be an out of memory problem
sooner or later.

By the way, I found that there is no need to store the temporaries as
children of a class. If they are created with a naming convention,
e.g. by using "new", they can easily be found and recognized simply by
walking through the instances of a class.

> The call to "gc" does not necessarily have to occur at the "end of a
> program". Think of a server program intended to run for an indefinite
> period of time. If this program creates "temporaries" continuously,
> without garbage collection there will be an out of memory problem
> sooner or later.

this is certainly an important requirement, but there is hardly a
general-purpose solution. rather, it requires application-specific
deletion procedures. for instance, there is active development of
XOTcl components for AOLServer and Naviserver, which provide worker
thread pools for connection and request handling. the thread pools
realise particular lifecycle models for the managed threads. Each
thread and the embedded Tcl interpreter go through certain
lifestages (cleanup, idleness, wakeup etc.). each stage is marked by
signalling events (e.g., cleanup) with application components being
registered as event handlers. For XOTcl objects, there is a
special-purpose destroy_on_cleanup() marker which registers the
receiving object for cleanup upon the thread and its Tcl interpreter
entering their cleanup stages.

see destroy_on_cleanup() and at_cleanup() in
http://fisheye.openacs.org/browse/OpenACS/openacs-4/packages/xotcl-core/tcl/01-debug-procs.tcl?r=HEAD

> By the way, I found that there is no need to store the temporaries as
> children of a class. If they are created with a naming convention,
> e.g. by using "new", they can easily be found and recognized simply by
> walking through the instances of a class.

indeed, introspection helps here, yet sometimes it is more convenient
(i.e., a finer-grained control) to allow each object to register for
deletion explicitly rather than have it deleted due to its structural
relationships (is-a, ...).

a final remark regarding volatile() in XOTcl: You can declare an
object volatile at any time, you are not restricted to its creation
time:

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 instproc foo {} {
  Complex c1 -real 2 -imag 2
  Complex c2 -real 2 -imag 2
  set c3 [c1 + c2]
  # !!! declare volatile !!!
  $c3 volatile
  # !!!!!!!!!!!!!!!!!!!!!!!!
  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()

On 11 Mar, 09:57, stefan <stefan.sober...@wu.ac.at> wrote:
> a final remark regarding volatile() in XOTcl: You can declare an
> object volatile at any time, you are not restricted to its creation
> time:

What I'd like to see from these "volatile" schemes is for there to be
a way to say "I want to expand the scope of the volatility". For
example, to be able to do this:

  set o [FooBar new]
  $o volatile
  # ... blah ...
  # Discover that we want the caller's lifetime to manage instead
  $o return

In that case, it would be like [return $o] except that it also adjusts
the volatility scope too. If volatility is implemented with an unset
trace on a local variable in the caller's scope - which is how I'd do
it - then this is just a matter of changing the registration so it is
instead registered on the variable in the caller's caller's scope, and
then a two-level return. Which sounds more complex than it really
is. :-) I've not looked how XOTcl does it, but it seems that this
would be something that could be done with little effort if you're
doing stuff in the "lazy simple sensible way".

Donal.