I've been revisiting this stuff after having worked on the TclOO
implementation for a while. So it's time to reignite the firestorm!

Twylite wrote:
>  Poor choice of words on my part.  The Tcl API for the core OO system
>  needs to be stable and fully specified before the official release of
>  the Tcl core containing that OO system.  i.e. we can still (if we have
>  to) fiddle with the API during Tcl 8.6a and Tcl 8.6b, the API needs to
>  be stable by Tcl 8.6rc, and the implementation needs to be stable and
>  correct by Tcl 8.6 REL.

I'd hope for a fully stable API (both at the Tcl and C levels) by 8.6b1.
Mind you, I'd hope for that with or without OO support at all. :-)

>  What we cannot have is a partially specified thing added to the core.
>  If TclOO was added to the core as-is then its current behaviour becomes
>  the specification - you can't say "oh, implicit variable access would be
>  nice, let's add it for 8.7" because that affects backwards compatibility.

All features that are proposed are fully specified, or at least should
be (if not, that's a bug in the spec). The discussion of variables was
relating to a feature that is not (currently) proposed, and as such, has
no specification. (Obvious, really.)

>  But not this one.  The argument I'm making is that the core OO system
>  should be (a) an OO system not just a framework, and (b) very
>  lightweight.

I've got sympathy for your aims. It's important to provide at least some
seeds for the whole system, even if not a whole class library (since
that's a lot of work!) One of the principles of TclOO's development has
been "don't write the class library".

>  By lightweight I'm talking about limitations that don't
>  affect simple tasks but would be unreasonable to handle complexity, e.g.:
>  - Single inheritance only, no mixins, no filters/guards/whatever.

Alas, it's very hard to add those features back if you remove them. In
particular, it's extremely difficult to add back multiple inheritance
(which mixins are just a variation on) since that affects how you do the
construction of the method dispatch chain.

>  - Either class-based or prototype system, and dynamic classes are
>  unnecessary
>  - Feels, smells, looks and quacks like Tcl.  Interacts well with
>  namespaces and how people are used to using Tcl.

Ah, but dynamic classes are Tcl-ish. After all, you're used to being
able to modify a namespace after you've executed code in it. :-)

>  - Some sort of support for widget creation

Again, this is a class-library thing. On the other hand, I think it's
largely independent of how the lower-level OO system works. It should
actually be mostly a matter of just a fairly small amount of (probably
rather clever) script-level coding...

[These are Gustaf Neumann's points]
> > One unclear point for me is, what the TCT community wants:
> >  a) a single OO language without bells and whistles
> >  b) a full-featured OO language better than python & friends
> >  c) a framework, to host other OO flavors
> >  d) a better C-Level API to get better and faster OO implementations
>  I believe TIP #257 states and justifies a bunch of goals.

The other thing that's really important for a core OO system is that it
*must* be fast. We *will* be subject to extensive examination that way,
whether we like it or not. Evidence collected last September (see part
way down http://wiki.tcl.tk/18152) is that XOTcl 1.5.5 was a distant
third behind TclOO 0.1 and itcl 3.4.0 for both object construction speed
and method call speed. Now, those figures are clearly out of date -
they're moderately annoying to capture too, so I've been putting off
another round of formal measurement - but they indicate that there are
aspects where TclOO really does lead the pack.

Note that you can see exactly the methodology I used to perform the
comparison. If it's wildly off, please say so. I tried hard to make it
comparable between the five systems, having them all do the "same" thing.

[These are Gustaf Neumann's points]
> > For (a) tcloo is not the best choice, since it cloned already many bells
> > and whistles from XOTcl in some way.

FWIW, it leaves out a lot of things from XOTcl that are (probably)
unacceptable in a full core OO system. An example is that in TclOO, you
can use [upvar] in a method in exactly the same way you would in a
conventional procedure, irrespective of how the method is overridden by
subclasses; so far as I can tell, you have to take additional steps to
achieve this in XOTcl.

> > For (b), a downstripped XOTcl
> > would be the simplest option,

Assuming you accept that XOTcl is simple. (Very clever, sure, no
dispute, but simple?)

> > for (c) TIP #279 is where to go
> > (could also help with a simple base language in (a), or goal (b)),

There is insufficient evidence to either support or debunk this
assertion, due to critical functionality being undescribed or
underdescribed. I propose to ignore any further statement on the
functionality of the interface proposed by that TIP until this lack of
description is resolved. (A complete description only exists for
"::oo::setrelation". A partial description exists for "::oo::alias", but
there is a lot of important details missing. The other key components,
including the dispatcher, are only sketched at best.)

> > or (d) might help tcloo, xotcl, snit, itcl from the C-level.
>  I concur with this analysis.  Not that it really gets us any closer to
>  solving the problem ;/

Of the object systems with C APIs, the strongest and maturest is
probably that of [incr Tcl]. TclOO is just a runner up in that category.
XOTcl doesn't document its C API at all, at least as of 1.6.0, the
current release. (Snit and stooop don't have C APIs, being pure-Tcl OO
systems.)

Donal.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core