Version 21 of TclOO WishList and Work Roster

Updated 2009-06-18 21:45:32 by dkf

DKF: Not everything that I want in TclOO is yet there. This is a page to collect those ideas and track them until they're implemented and deployed in reality.

Warning! What TclOO won't do is massively increase in scope. Its focus will necessarily remain on being small, stable, fast, well-engineered, tested and documented. Putting any old thing in here may well just result in those suggestions getting deleted. You are supposed to build on top of TclOO for most things.

Wish List

The order here is arbitrary.

Fundamental features

  • submethods (to support Snit)
    • Not yet TIPped.
      • Difficulty estimated to be fairly high; introspection is troublesome…
  • slots (to support XOTcl)
    • See TIP#279 for background ideas. [L1 ]
      • Difficulty estimated to be fairly low
  • better support for self-like object management
      • Difficulty not yet studied
  • garbage collection
    • Not very hard to implement, but doesn't follow Tcl's basic semantic model so nasty (but can use techniques like tcom and tclblend do...)
  • class methods
    • On one level, easy (especially with info object namespace). But what is the benefit? How do they vary with respect to instance methods?
      • LV: Well, an example mentioned in Wikipedia's page on class methods mentions that one use might be a class method used to keep track of the number of instantiations of the class.
      • DKF: Sure, but TclOO classes are real subclass-able objects themselves, which makes this all more complex (are the class methods really just methods of the class?). It's wrapping my brain around the concepts so I can work these things out that's hard. The code is the easy bit; I can hack it in the constructor with suitable forwards at the moment...
    • Easy to implement, hard to conceive.
  • class variables
    • Current version makes it easier to get the address of a variable in the class and so bind it to the variable in the object.
      • Probably understood now, so pretty easy.
  • more powerful method forwarding rules
    • though the HEAD can use a namespace-d command to handle the fancy bits (older versions had an issue with the resolution context for forwards that made them near useless...)

Class library

  • megawidget system
    • Base on Megawidgets with TclOO? Should be (nearly?) pure Tcl.
    • Part of the 8.6 tk_getOpenFile for Unix/X11 is currently done as a TclOO-based megawidget, which simplified quite a lot of code.
  • Support for chan create and chan push
  • Rework zlib stream stuff as TclOO class
    • Requires C skills.
  • TDBC (though this is really already done)
  • Improvements to tcllib
    • Should be pure Tcl.
  • Serialization
    • I've already written a package for Serializing TclOO objects so this is mainly done, at least for simple code; it's things like object versioning and what to do about classes that needs to be thought about now.

Work Roster

[to be done]

See Also


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 new

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