Re: Itcl and TIP#257

Donal K. Fellows a écrit :

[...], it should be possible to back the objects onto some shared
variable (using the Thread package?) and send messages back and forth so
that when one view-object goes away, so do the others. (Assuming that's
what is wanted by a thread-shared object, of course.)

Couldn't we create a new command for Incr Tcl that makes
(optionally would be fine) use of the Thread extension to share data
with other interpreters.

Such as :

class Foo {
private shared variable myvar ""
...
}

The [shared] qualifier should force ITcl
to handle this perticuliar variable somehow
special.


1) In each thread you might need the
shared variable, call :

new Foo $id <args>

The name '$id' should be the same across
multiple threads, but still created on demand.

2) Each read access to myvar should call:
tsv::set Foo::$id myvar

While much write access to myvar should call
the matching {set incr append lset lappend}
whenever possible.

Example :
{incr myvar} in a method is changed into this:
tsv::incr Foo::$id myvar

3) Common variables (static?) may also be shared
across multiple threads, but in the tsv::set calls
we should replace "Foo::$id" by "Foo::class".

tsv::set Foo::class mycommonvar ?value?


=========================
This approach would not cost much, but
I see one major drawback, which is solved by
shared *objects* : the initialization of these
shared variables.

In constructors, great care should be done
on how shared variables are set.
Indeed we are not like in Java, but with shared
data between two objects, instance-shared
variables instead of class-shared variables.

I must admit it is not a very good idea, but
perhaps it may help you to see other
points of view. :-)

Cheers,
Stephane

.