• slots (to support XOTcl)
  • See TIP#279 for background ideas. [L1 ]
    • Difficulty estimated to be fairly low
  • See TIP#380 [L2 ]
• better support for self-like object management
  • See TIP#397 [L3 ]
• TDBC

Work Roster

[to be done]

See Also

• Tcl 9.0 WishList
• Tk 9.0 WishList

Discussions

GPS - Regarding garbage collection I think you grossly underestimate the difficulty in implementing that. It would require significant and invasive changes to Tcl to have garbage collection of TclOO objects.

Consider this example (taken partly from the oo::class manual):

 % oo::class create fruit { method eat {} { puts "yummy!"}}
 ::fruit
 % fruit new
 ::oo::Obj4

What happens if a user writes a reference for ::oo::Obj4 with: puts $socket $someObj; and then they later expect to: set someObj [read $socket] and have a usable $someObj? Files are a similar case. If you have a GC and I/O subsystem that doesn't understand how to reconstruct an object from a class, it will fail. That means you would need something like Java's ObjectOutputStream and ObjectInputStream. There are other issues as well. Will you require that all variables storing TclOO objects be declared? What happens when you do:

 set foo [list [fruit new] [fruit new] blah]

How will you know what a reference is, unless you declare the variables that can store TclOO objects? C extensions that store strings could be storing the handle to an object, so that means requiring C extensions to register possible references. The idea of GC for TclOO would require a different design, and a different language at the moment. I think I have made my point regarding the "not hard to implement."

Does that mean it's impossible? No. If you pass around all of the state for a TclOO object with each Tcl_Obj, rather than a handle, it would work. So every object would be a serialized representation. That would require syntax/implementation changes though for TclOO.

DKF: I don't think I underestimate the difficulty. There's a good reason why I've not actually put any effort into implementation of it yet. (Thanks for reminding me about serialization; that's a separate item for the wish-list.) I'd not expect to get a usable object if I just sent the handle via a socket, but I'd also expect one to have to take a special step to serialize when sending. The reason I say "not hard to implement" is that there is that existing experience in several extensions, but the implications go very deep; either the handles are fragile or they're mutable, and both are fundamental changes to Tcl's value semantics. As I said, there's a good reason why I've not actually put any effort into implementation of it yet; this rabbit hole is deep.

Note that when it comes to serialization, you have to distinguish carefully between the objects and the handles to them. This is made more awkward by the fact that we have two different types of handle to deal with: direct handles (the official name) and indirect handles (via the namespace).

mpdanielson - Is the plan to make class variables similar to variables? It would be nicer to say

oo::class create C {
  classvar x
  set x 42
  method printx {} {classvar x; puts $x}
}

than

oo::class create C {
  self export varname
  set [[lindex [info level -0] 1] varname x] 42
  constructor {} {my eval upvar [[self class] varname x] x}
  method printx {} {variable x; puts $x}
}

DKF: That was my thought, yes. After all, they'd still be annoying to use otherwise.

JBR 2009-11-21 : You cannot yield from a method that is behind a filter. The filter pushes a layer on the C stack. DKF are there any other places in TclOO which push the C stack?

DKF: You can so far as I can see:

% oo::class create c {
    method foo {} {yield 1; yield 2; yield 3; return 4}
    method Bar {} {puts before; set v [next]; puts after; return $v}
    filter Bar
}
::c
% c create o
::o
% coroutine coro o foo
before
1
% coro
2
% coro
3
% coro
after
4

Looks like it is working to me.

JBR - Yes I see that. I must have been doing something silly, now I have to figure out what - Thanks.

AMB - 2023-09-22 14:00:24

I created a package that implements garbage collection for TclOO, in pure Tcl.

The page for it is here: vutil.