Author: Kevin Kenny <kennykb@acm.org>
Author: Mark Harrison <markh@asiainfo.com>
Author: Jeff Hobbs <jeffh@ActiveState.com>
Author: Andreas Kupries <andreas@ActiveState.com>
Author: Karl Lehenbauer <karl@procplace.com>
Author: Michael McLennan <mmc@cadence.com>
Author: Don Porter <dgp@users.sourceforge.net>
Author: Brent Welch <welch@acm.org>
State: Final
Type: Informative
Vote: Done
Created: 27-Jul-2001
Post-History:
Abstract
A "town meeting" discussion in which users were given the opportunity to question the Tcl Core Team at the 2001 Open Source Convention has revealed a great popular demand for bundling an object system with the distribution of the Tcl Core. This TIP presents a compromise proposal for including [incr Tcl] that was acceptable to all eight TCT members present.
Proposal
[incr Tcl] http://tcltk.com/itcl/ shall be bundled with the core Tcl distribution.
[incr Tcl] shall be "included" in the Core in only a weak sense.
> The location of the [incr Tcl] source tree shall be left to the discretion of the affected maintainers. \(It appears likely that most [incr Tcl] source will appear in a separate _itcl_ directory parallel to the _generic_, _mac_, _unix_ and _win_ directories in the source.\) > [incr Tcl] shall be built as a separate loadable package, similar to the _dde_, _http_, _msgcat_, and _registry_ packages. > The _::itcl_ namespace shall be the only new component included in the global namespace, and shall appear only when a script executes package require Itcl > There shall be no _::class_ command in the Core. > The _::info_ command shall not provide any subcommands specific to [incr Tcl].[incr Tcl] shall not be substantially modified under the scope of this TIP.
> The existing issues surrounding errors thrown from object destructors shall not be addressed. > The existing use of _rename_ for object destruction shall not be amended. > All other limitations of [incr Tcl] are initially accepted as they are. > Of course, additional TIPs could be submitted to modify [incr Tcl] as desired!The TCT shall assume the role of gatekeeper for changes to the functionality of [incr Tcl].
> Changes that affect user-visible functionality of [incr Tcl] shall be made through the TIP process. > Informational TIPs identifying maintainer areas and assigning maintainers to them shall be developed.Nothing in this TIP shall be construed as identifying [incr Tcl] as a single preferred object system for Tcl. If the community desires other systems such as OTcl, XOTcl, or ObjecTcl to stand on an equal footing to [incr Tcl], their champions can introduce TIPs similar to this one.
[incr Tk] and [incr widgets] are outside the scope of this TIP.
Rationale
The lack of a standard object and data abstraction system continues to hinder Tcl development.
"Lets face it, not including any sort of OO system is one of the major failings of Tcl. Indexing into global arrays is a sad hack when compared to a real OO system." - Mo DeJong mdejong@cygnus.com
Moreover, the argument that "Tcl is not object oriented" continues to hamper Tcl marketing. Including at least one object system with the Tcl core, so that it is dependably available unless the user has built from source, would address this objection.
Since an earler proposal ([6]) to incorporate [incr Tcl] into the Core failed to garner the necessary votes, at least in part because participants were uncertain of the rationales, it seems wise to discuss the individual points in further detail.
All agree that some sort of object system must be bundled with the core so that it is dependably available. [incr Tcl] appears to be the most popular of the existing systems, as well as the most familiar to the current TCT, making it the most attractive of several candidates for this role.
The original [incr Tcl] developers have pointed out that bundling in the Core would facilitate [incr Tcl] development greatly. While it is a separate loadable package, [incr Tcl] is intimate with the core, depending on many undocumented interfaces to carry out its functions. Integrating it with the Core would make it easier to maintain.
Including a ::class command in the Core is not acceptable at this time, because it would have the effect of disenfranchising the users of other object systems -- who are too numerous to ignore. Moreover, the ability of Tcl to serve as a test platform for novel object models must not be compromised.
Similarly, integrating [incr Tcl] closely with commands such as ::info or ::destroy would accord it a privileged status that the users of other object systems are reluctant to accept.
[incr Tcl] is what it is. It would be inappropriate to demand that all the perceived shortcomings of the [incr Tcl] system be addressed prior to inclusion in the Core. The TIP process is available to make further changes; the system is certainly good enough that many thousands of programmers use it daily.
If [incr Tcl] is to be included in the Core, then common sense requires that it be under control of the TIP process.
Alternatives
Include [incr Tcl] in a "batteries included" (BI) distribution.
> Many people will not opt for the BI distribution \([[4]](4.md)\) due to its larger size. It is quite likely that \(for example\) a Linux distribution my include Tcl as a standard component, but place the BI on a supplemental disk. > Moreover, as mentioned above, the [incr Tcl] sources are already intimate with the Tcl core; there are great maintenance savings to be achieved by combining the source distributions.Integrate [incr Tcl] tightly into the Tcl Core.
> This alternative is unacceptable to a good many users. A number of attendees at the 2001 Open Source Convention mentioned specifically that they use alternative object systems such as OTcl. These users would be essentially disenfranchised if, for instance, a _::class_ command were to appear in the Core.
Implementation
Jeff Hobbs has volunteered to lead the implementation effort with the assistance of all volunteers who want to help.
Notes
Eight members of the Tcl Core Team (Harrison, Hobbs, Kenny, Kupries, Lehenbauer, McLennan, Porter and Welch) agreed orally to this proposal at the 2001 Open Source Convention. Since not all have had the opportunity to read the formal written version of the proposal, that vote shall not be considered binding.
References
Copyright
This document has been placed in the public domain.