[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 [TIP]ped. *** Difficulty estimated to be fairly high; introspection is troublesome… * '''slots''' (to support [XOTcl]) ** See [TIP]#279 for background ideas. [http://tip.tcl.tk/279.html] *** 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 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] ** Base on [TclOO Channels]? Should be pure Tcl. * Rework [zlib stream] stuff as TclOO class ** Requires [C] skills. * [TDBC] (though this is really already done) * Improvements to [tcllib] ** Should be pure Tcl. ---- **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... ---- !!!!!! %| [Category Suggestions] | [Category Object Orientation] |% !!!!!!