My perspective is that I am happy to use, or not to use, OO systems in 
applications on an ad-hoc basis.  I'm happy to have multiple OO systems 
intermixed with non-OO tcl within the same application.  I'm sure 
there's a perceived need for tcl to have some OO systems easily 
available to programmers.

Hoping to add some diffuse light and not *too* much heat (as an onlooker 
with no particular investment in OO,) I offer the following opinions.

Tcl's goal is to be a language.  TclOO's goal is to add support for OO 
to the core tcl language.  That is the remit and duty of the TCT: to add 
facilities as needed to the core language in order to produce a 
*maintainable* and *useful* language.

Xotcl's goal is to be an excellent OO language/system, to experiment 
with and explore in that field.  The choice of tcl as a 'host' or base 
language is subsidiary to that goal.  Similar considerations would apply 
to other OO systems.

I don't see why these goals are incompatible as a matter of theory.  If 
they are, then this says something interesting about the nature of OO.

Satisfaction of both of these goal sets are to be sought within an 
economic field - one must work within the available resources to achieve 
one's goals.

What is needed is a process of negotiation and engineering.  That is 
what the TIP system is supposed to foster and represent.  A TIP is a 
proposal for engineering effort to a specified end.  A TIP + 
implementation represents a proposal and a good deal of sunk cost in 
terms of engineering effort.

TIPs are also the only way additional functionality in code is added to 
the tcl language core.  That's because accepted TIPs represent a 
committment by something called the TCT to encourage developers to 
implement and maintain accepted specified functionality.  Accepted TIPS 
seem to me to be akin to a social contract for the donation of effort to 
a common end, mediated by TCT.

All of the available OO systems (I include TclOO in this) represent a 
great investment in OO and tcl.  TIP 257 is tcl becoming-OO (bottom-up), 
xotcl, itcl, etc are OO languages becoming-tcl (top-down).  The hope of 
TIP 257 is that there would be a meeting in the middle, at a point which 
TCT could recommend and encourage developers to develop and maintain.

I get the impression that it's the considered opinion of TCT-developers 
(those who are on the TCT and are developers) that neither itcl nor 
xotcl are good engineering choices for an interface between tcl and OO 
systems.  It is therefore not surprising that TCT will not recommend 
them as appropriate core interfaces.  The reasons for their 
unwillingness includes that they don't feel they have the time, or 
available expertise, or commitment from relevant experts, to maintain 
the non-tipped OO systems as core components.

If I were responsible for maintaining tcl core, I would not be prepared 
to 'bless' or adopt, recommend, encourage or oblige future developers 
and users to support and maintain an interface which I was not sure 
could be economically maintained or developed.  I think TCT is behaving 
responsibly in trying to ensure that whatever OO interface is adopted is 
maintainable with those resources they reasonably expect to be 
available, and to be able to influence.

I may be seeing things one-sidedly, because I would rather see all OO 
disappear than see tcl core language changed in a way that made it less 
maintainable by the TCT developer pact.  On the other hand, but to a 
lesser extent, I would rather see tcl core gain an OO system than not 
have one.

It seems to me that the best opportunity to negotiate a meaningful, 
functional, useful interface between tcl and all extant and possible 
future OO systems is TIP 257, which has been on the table for months, 
and which opportunity has been largely left untaken.  TIP 257 represents 
a considered attempt to interface between tcl core and *all* OO systems, 
and an opportunity for any particular OO system to negotiate a preferred 
interface through the dual processes of robust discussion and 
cooperative work on example code.

I do not think that an appropriate response to the problem of extending 
tcl core to include OO is to slap down an extension and say 'there it 
is, it works, use it,' without giving at *least* as much consideration 
to the impact on tcl core, TCT/developer economics and non-OO users as 
is given to the problem of excellence in OO.

I know Donal well enough as an engineer to know that he's been available 
for negotiation of the tcl core interface, and I feel sure that he would 
have been happy to modify his approach to accord with timely and 
well-reasoned OO-excellence arguments.  I know Donal well enough as a 
TCT member to know that he has TCT-responsibilities uppermost in his mind.

In summary:  the issue is not 'what is excellent OO?' but rather 'what 
excellent OO can tcl have?' and to the extent that the proponents of 
excellent OO systems have been disengaged from the TIP process, working 
with TCT-facing developers to negotiate a tcl-appropriate excellent OO 
system interface, they have done neither tcl core nor OO any service.

There is no obligation on the part of OO proponents (of any stripe) to 
participate in TIPs, unless they desire a tcl core inclusion.  There's 
nothing wrong with maintaining an OO component as an extension, if the 
TIP process is not to a developer's taste.

What matters is:  how can excellent OO be added to tcl core such that 
TCT can recommend to developers that they maintain and implement the 
adopted (TIPped) interface?  It seems to me that waiting until a 
significant TIP-investment has occurred before engaging in 
TIP-negotiation and development leaves one with very little scope to 
argue against it in good faith.

Colin.


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core