Damon Courtney wrote:
>       XOTcl has been around for years.  Gustaf and the team have put in  
>  a lot of work, and I would say they have the most knowledge of OO in  
>  this community and especially with regards to Tcl.  So, how do we  
>  reward that knowledge and hard work?  Let's go off and make ANOTHER OO  
>  EXTENSION!  This REEKS of "not invented here."

XOTcl is, to my mind, one of those things that you either buy into or
don't. I think that a core OO system should be simple and stay out of
the way of the code that people write with it, so that people can make
their own scripted and C-level APIs. The primary thing that needs to be
in the core is the dispatch engine, because that needs to be fast; it's
totally on the critical path for any OO system (except maybe for stooop
which is strange and very C++-like in that respect).

>  If you don't like XOTcl, clean it up.

As far as I can tell, it lacks a documented C API (I'm looking at the
1.6.0 download package). You integrate with extensions coded in C via
forwarded methods, which is perfectly OK as _a_ way to do it, but is
less acceptable as the only way. What I can't do with XOTcl (correct me
if I'm wrong here!) is implement my own *types* of method in third-party
extensions. (Nor can it support sophisticated things like the way that
itcl's superclass dispatch works, or at least not in the general case.)

>  It's the best we've got.

In terms of sophistication of Tcl API, quite possibly. In terms of
engineering quality? I think some of the comments you made below would
indicate perhaps not.

>  TclOO sucks memory like a damn mind flayer (gratuitous D&D
>  reference).  It uses more than Itcl, for God's sake.  Remove the cruft  
>  and crap and make XOTcl (a tried and tested OO extension) the core.

That's quite tricky. xotcl.c is 13kloc, with not that many blank lines
or comments. It's also written using a denser coding style than Tcl or
Tk (which are deliberately fairly sparse even before allowing for
commenting). The net result is that figuring out how to improve that
code is distinctly difficult, and would require more investment of
effort than I'm personally inclined to do. (Frankly, at that level of
complexity, I'd almost rather jump into maintaining the stygian joy of
Henry Spencer's magnum opus.)

Figuring out where it is consuming memory is something for experts; I'm
no expert on the implementation, so all I can do is provide advice once
someone else identifies the issue. I suspect, and this is not grounded
in deep code inspection and so may be way off base but is founded on a
quick scan of their implementation of [next], that the problem is the
number of stack frames it uses. (TclOO uses a different approach that is
much lighter weight.) Reducing the number of stack frames is *hard*
since that's almost certainly a deeply ingrained assumption.

>  Change instproc to method or whatever you've got to do.  WORK WITH  
>  THEIR TEAM.  They know what they're doing, and they actually WANT TO  
>  DO IT!
>  
>  God damn it, guys.  Grow up and work together.

Until I hinted that I was going to call the vote, I'd not heard a word
for 18 months. I do other things than argue with folks over OO system
implementation differences, such as work!

For the record, I do not believe that (based on current evidence of
suggested implementation) that TIP#279 can be implemented before October
1st. It's just too much work given resources available, given that XOTcl
itself is not in a suitable state engineering-wise for adoption.

Donal.

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