Larry McVoy wrote:
> > (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, ...).  
> >     
> 
>  So that would argue to stick TclOO into the core?
I think that would carefully avoid arguing anything ;)

TclOO has crufty-like stuff that should not, in my opinion, be in a
lightweight OO system.  Filters need to go, perhaps mixins.  I don't
deny their usefulness, but I think they are features best left to a
heavier weight OO system.
It needs to decide whether it is a class-based or prototype system.
Does it really offer the typing guarantees that a class-based system is
meant to have?
There needs to be a clear definition of all aspects of the behaviour
(like whether member variable access from methods is implicit or
explicit, are classes dynamic, etc).
The Tcl API needs to obey the Principle of Least Surprise, and my
feeling is that it doesn't in places.
There needs to be a clear way to implement widgets using the system.
Clear in the sense of "do this, don't RYO", in other words widgets must
be natively supported by the system.  Otherwise we'll just see a new
megawidget framework in each widget library.

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