I'm not going to reply to anyone in particular here, but just air some 
views.  It makes me feel better ;)

(1) I don't believe that Tcl should have Only One OO system. 
A lot of people think there should be Only One OO system because they 
are concerned about the proliferation of micro- (and not so micro) 
object systems; and because they are used to thinking in terms of other 
languages that "have OO support" - meaning only one way of doing OO.
Tcl has an almost unique advantage of allowing you to extend the 
language syntax, not just the commands/libraries.  As a result the core 
has stayed light and simple making it highly usable for low-complexity 
tasks.  And if you need the additional power of a do...while or a 
try...catch...finally or data structures or whatever, then you just pull 
in the appropriate extension.
So I think it is entirely appropriate to have "lightweight OO" in the 
core, with a more capable OO available as an extension to those that 
need it.
This also circumvents the class-based vs prototype argument, and neatly 
handles concerns like the perceived movement from inheritance to 
composition as a design preference.

(2) On the proliferation of micro-object systems (or Do we need core 
support for OO?).
To my mind the reason for the proliferation of micro-object systems is 
obvious: the heavyweight OO systems are complex, overkill for simple 
tasks, and are binary extensions (restricting their availability).  
There is no single, lightweight, pure-Tcl OO system that is recognised 
as being "the standard".  And writing a micro-object system is 
(relatively) easy, so the barrier to entry is low.
How can we counter this?  We can't make it more difficult to write 
micro-object systems, and if we put a heavyweight OO system in the core 
that is not straightforward and simple to use then it may be avoided for 
a simpler RYO solution.  So we must adopt a lightweight OO system into 
the core.
This must also be done _soon_ so that further micro-object systems are 
avoided, and work can begin on migrating existing code bases (like 
tcllib) to the new core OO and improving their performance.

(1) + (2) = Put lightweight OO system (not just framework) in core, and 
do so soon.  Expect users to resort to extensions for heavier lifting.

(3) Implicit vs explicit access to private member variables in methods
In the core: explicit, with _optional_ support for implicit.
Why?
(a) You can add implicit on top of explicit, but not vice versa.  So by 
forcing (as opposed to supporting) implicit member variable access you 
deny the option of explicit access to those who want it.
(b) Implicitness of access is inconsistent: you must ensure that access 
is explicit the first time you set the member variable (which is not 
necessarily in the constructor), and it can be implicit thereafter.  
This can lead to subtle bugs.
(c) The idea of implicit access is inconsistent with the rest of Tcl: 
when writing or reviewing object code you must put yourself in a 
different frame of mind in which you have to think about variable scope 
& overwriting, where Tcl's usual behaviour is shadowing.
(d) Implicit access is unsafe and complicates refactoring: a developer 
adding a new method 2 years down the line may decide to use the member 
variable "myValue".  Any local variable "myValue" in another method of 
the same class could be instantly promoted to being a member variable 
(so much for Least Surprise).  Even if the developer knows about this 
potential catch there is no central record of all member variables (like 
a C or Java class definition) because they are all dynamic.

(4) What's wrong with XOTcl?
XOTcl has a bunch of great ideas BUT:
- While the rest of the world talks about methods/operations, 
attributes/fields and properties, XOTcl invents the terms instproc, 
instvar, and parameter/slot.
- Functionality like filters and pre/post-conditions, even parameter 
rewriting in forward, belongs in Tcl as a whole, not just the OO 
extension.  This is also the "heavyweight" bit that doesn't belong in 
the Tcl core.

(5) What's wrong with TclOO?
- It needs to specify variable/state behaviour.  Before release.  It is 
doesn't do so then however it is implemented effectively becomes the 
(undocumented) specification.  This may not be a recipe for disaster, 
but certainly is one for arguments.
- It has extra bits like filters.
- Something about it feels wrong, perhaps hacky.  It seems to have an 
incestuous relationship with namespaces without actually looking like 
namespaces, which is what a lot of developers thought would be least 
surprising in an OO system.

(6) What to do?
(a) Implement TIP #131 instead.
(b) Failing which, I think the answer lies somewhere in between TclOO 
and XOTcl-minus-the-extra-bits (like filters, assertions, ...).  
Something that feels like Tcl (XOTcl often doesn't), sounds like UML, 
makes it easy to create _and extend_ widgets (including core widgets), 
doesn't surprise developers, is well specified and documented in all 
aspects.
(c) If I knew how to do that, I would have done it by now ;p

Regards,
Trevor



-------------------------------------------------------------------------
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