From: Trevor D. (Twylite) <tw...@cr...> - 2012-11-20 14:58:06
|
Hi, On 2012/11/20 04:22 PM, Karl Lehenbauer wrote: >> A move to version 9 is a once-in-a-long-time opportunity to break backwards compatibility. While I'd love to see a Tcl 9.0 out of the door in a reasonable time, decisions about what compatibility to break - or not to break - should not be taken lightly or hastily. > It is true that I am pushing for a greater sense of urgency and productivity toward a release. If the 9.0 release takes four years to produce, we will have spent our time polishing a corpse. You'll find no argument here ;) I'm also grateful to Will Duquette for his clarification that the TCT may be willing to break backwards compatibility during the 9.x cycle, which affects the point I was making. > I'm not super educated on all the ins and outs of the things you said are important, but I'm a little leery -- I browsed the proffered links fairly superficially but what I saw were fairly spare conversations that have been going on intermittently for nearly a decade. (That alone, people started Tcl 9 wishlists in 2003!) I don't see a lot of agreement about how to do this stuff and I'm pretty sure I saw unanswered statements of what a big job it would be or how it would require reworking the entire core or how it may actually not even be possible. IMO we should not hold up Tcl 9 for things that are impossible. What I think is really important is that there is a period to entertain these ideas and determine whether they will require backwards-incompatible changes, before committing to a definition of Tcl 9.0 that will forever preclude their implementation. Looking back at my suggestions: Leading Word Expansion could be added later with only small impact for backwards compatibility, and so could a solution to the command/variable dichotomy (i.e. look up the leading word as a value, expand the value as a list). By Will's description this could be considered later in a 9.x cycle, rather than only at 9.0. I'm far more concerned about Tcl_Obj, since it is defined in tcl.h. Without a version/magic field, or a guarantee that only core C API functions can constructor/allocate and free a Tcl_Obj, it is not possible to extend Tcl_Obj. My understanding is that we can't extend Tcl_Obj (and discussions about how to steal and repurpose bits from the refCount would seem to support this). Without extending Tcl_Obj we can't have a value-specific free() function in addition to (or as an alternative to) the type-specific free, and that is precisely the functionality needed to enable (some form of) closures. Discussions around Tcl_Obj changes probably also impact on the DGP/Nitjmans conversation on whether extensions built against 8.6 can load into 9.0. Regards, Twylite |