Philip Quaife 17 Jan 05 - Freeing the core for all
There is a lot of discussion on what should and shouldn't be in the core of tcl/tk.
I propose a simple way to end this endless and mostly pointless debate whilst enabling unbounded testing of new features. The aim is to put the work extension back into tcl.
There are two principle areas to address:
Central Repository
While the TCT provides a focal point at tcl.sf.net for getting the core interpreters, there is no central repository for extensions.
No group of users or Company has committed to providing a long term storage area for either source or binary extensions.
This means that new users have to go to conciderable effort to locate an extension (once they are even aware of it), then they must most likely comile it themselves only to find that it needs some tweeking to be compatible with the latest version of tcl/tk.
I don't want to debate the case for or against a central repository, but it cannot be denied that the lack of one provides an impediment to new users getting the maximum benefit out of tcl/tk.
Once there is a central repository (this does not preclude the repository from being implemented as distributed system), we have the ability to add features such as:
Why is being in the core so important?
Partly because of the above. Without being in the core you don't get exposure for your code. Most importantly , if you want other people to try out your code and it has features that are not in the generic core , you require the other users to update there core system.
This automatically cuts down the exposure to those users that have both the time and the skill to do so.
While most core feature additions are made with dynamically loadable extensions, some of them require modifications to the core interpreter.
Replacable Core API
When the extension of TCL requires modiciations to the tcl/tk base code it requires a formal process to have the change implemented.
This is because it affects all users. Once the change has been made we have made that the default feature for all users.
Contrast this with extensions, these can be loaded or not at the application writers discression. A new extension does not affect existing users.
Quite often the change wanted is only wanted by a small number of tcl users or just as an accademic exercise by one person seeking input from the programming community.
In these cases it is not applicable to make a permanent change to the base functionality.
To merge the two disparate needs we can simply do the following:
Before we start posting objections to why this can't be done , won't work and other unfounded remarks. Take a pause and have a deep breath.
I am not going into the technical details of how this would be implemented, but I have spent enough time analysing the core to know that it is quite feasible, amenable to change by automated scripts, and something that the tcl community could do collectively in a short space of time.
The last change proposed alieviates the need to make internal structures extendible. While not necessary it does provide a unified structure that would alleviate some work on the part of extension writers. And of couse there will be someone out there that will want that feature in the future.