Re: [Xotcl] "tie" command
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 24 Jan 2003 16:43:25 +0100
On Friday 24 January 2003 15:16, Kristoffer Lawson wrote:
> On Fri, 24 Jan 2003, Gustaf Neumann wrote:
> > we could provide an option -bind <varname> to the new instproc to allow
> > the user to specify a local or a per-object or global variable name,
> > but
> > this does not provide reference counting at all. i have started some
> > time ago
> > to work on reference counting, and xotcl has some good prerequirements
> > for this: we have tcl_objs for xotcl objects, they maintain already a
> > reference count. the obvious idea is to destroy the object, when the
> > reference count reaches 0. however, practically this showed to be quite
> > tricky in the current implementation since the refcount = 0 condition
> > happens in some unvonveniant situations... i have not given up on this,
> > but it needs a bigger chunk of time to devote to this...
>
> Yes, exactly. Obviously it's all just steps to make some things easier
> while refcount based destruction is the absolute solution. However,
> as you may have noticed from c.l.t, ref-count -based systems are really
> nasty to get done properly. How would you propose to deal with the
> situation where a reference is lost, because the object just happens to
> be made into a string (ie. some command or procedure does not keep the
> Tcl_Obj but just uses the data as a command). F.ex. when building
> callback scripts and containing the object handle there, or as an array
> key (I think array keys are still just considered to be strings and the
> Tcl_Obj form is not retained).
sure, in general, this is an intrinsic problem. what i have
implemented already in 0.94 was a double refcounting, that allows
multiple tcl_objs to point to a single xotcl-object (or class), having
therefore refcounts on the tcl_objs and separate refcounts on the
xotcl-structures (classes and objects).
therfore it is possible to convert for example the string "Object"
with little effort to he class Object, as long it exists. For example
after the statement
Class C -superclass Object
Object is a TclObj pointing
to the appropriate xotcl-structure. So, this is not exactly the same
situation as the general case, where the string to object
mapping is not possible or leads to a new structure not
representing the old state.
Certainly, when all references are gone (stringified, only string callbacks
point to an object) the object will be destroyed.... still, we would
have the choice btwn traditional objects (that can be used safely
in callbacks) and refcounted objects, there are many cases,
where this might be useful ... i my code, i have not experienced
the problem with unneeded objects (people that grew up with
Java rather than C might thing differently)
-gusaf
Date: Fri, 24 Jan 2003 16:43:25 +0100
On Friday 24 January 2003 15:16, Kristoffer Lawson wrote:
> On Fri, 24 Jan 2003, Gustaf Neumann wrote:
> > we could provide an option -bind <varname> to the new instproc to allow
> > the user to specify a local or a per-object or global variable name,
> > but
> > this does not provide reference counting at all. i have started some
> > time ago
> > to work on reference counting, and xotcl has some good prerequirements
> > for this: we have tcl_objs for xotcl objects, they maintain already a
> > reference count. the obvious idea is to destroy the object, when the
> > reference count reaches 0. however, practically this showed to be quite
> > tricky in the current implementation since the refcount = 0 condition
> > happens in some unvonveniant situations... i have not given up on this,
> > but it needs a bigger chunk of time to devote to this...
>
> Yes, exactly. Obviously it's all just steps to make some things easier
> while refcount based destruction is the absolute solution. However,
> as you may have noticed from c.l.t, ref-count -based systems are really
> nasty to get done properly. How would you propose to deal with the
> situation where a reference is lost, because the object just happens to
> be made into a string (ie. some command or procedure does not keep the
> Tcl_Obj but just uses the data as a command). F.ex. when building
> callback scripts and containing the object handle there, or as an array
> key (I think array keys are still just considered to be strings and the
> Tcl_Obj form is not retained).
sure, in general, this is an intrinsic problem. what i have
implemented already in 0.94 was a double refcounting, that allows
multiple tcl_objs to point to a single xotcl-object (or class), having
therefore refcounts on the tcl_objs and separate refcounts on the
xotcl-structures (classes and objects).
therfore it is possible to convert for example the string "Object"
with little effort to he class Object, as long it exists. For example
after the statement
Class C -superclass Object
Object is a TclObj pointing
to the appropriate xotcl-structure. So, this is not exactly the same
situation as the general case, where the string to object
mapping is not possible or leads to a new structure not
representing the old state.
Certainly, when all references are gone (stringified, only string callbacks
point to an object) the object will be destroyed.... still, we would
have the choice btwn traditional objects (that can be used safely
in callbacks) and refcounted objects, there are many cases,
where this might be useful ... i my code, i have not experienced
the problem with unneeded objects (people that grew up with
Java rather than C might thing differently)
-gusaf
-- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik WU-Wien, Augasse 2-6, 1090 Wien
