Tomasz Kosiak wrote:
> From my understanding TIP#279 was created as there are problems in
>  implementing XOTcl on top TIP#257. Maybe I am wrong, but wasn't it a
>  showstopper for TIP#257 inclusion in Tcl 8.5.

Not as far as I can see. The authors of #279 haven't been doing a good
job at ensuring that there is a full implementation of the TIP without
the full complexity of XOTcl. (That complexity gets some people's backs
up, and they're folks that are already not using XOTcl.)

>  Developers in my company frequently ask me about an approved OO in
>  Tcl. I've heard that Snit works well for megawidgets - it seems that
>  there are developers successfully using it in real projects. But for
>  general OO uses  I feel that XOTcl is the only one Tcl OO extensions
>  that is practically used in substantial real life applications (like
>  OpenACS XOWiki developed by Gustaf Neumann and Archiware product
>  backed by Zoran Vasiljevic).

You'd be wrong there. [Incr Tcl] still has many deployed uses as I
understand it.

>  I think that it would be a real pity if we won't learn from their
>  experiences and make TclOO (as proposed by TIP#257) incompatible with
>  current XOTcl (TIP#279 presents an idea how to avoid that).

Having just reread it, The problem with that proposal is that it is
significantly underspecified. Of the core components it talks about, it
only actually defines oo::alias and oo::setrelation, and it leaves the
other parts (including the specification of the dispatcher)
un(der)defined. We can surmise that they're supposed to be something
like XOTcl :-) but the TIP doesn't actually say that. (The dispatcher
semantics are critical, FWIW, and so have to be *exactly* defined.)

FWIW, having agonized quite a lot over this, I think things are cleaner
if methods are not commands. The problem there is that methods need to
know the object call context as well as the things that a command
normally knows, and overloading that stuff onto the clientData is a
total abuse of the API promises.

>  I would liked TIP#279 authors and promoters to speak out how this
>  TIP#257 vs TIP#279 problem could be resolved.

My opinion is that the XOTcl dispatcher is probably correct in semantics
even if not necessarily the way I'd implement it. The setrelation
command could be done on top of #257 (modulo not wanting to let the core
object/class relationships be modified; some things are too chaotic to
contemplate). The alias command is assuming a particular type of method
implementation that I think is flawed, but could probably be written
without too much trouble once the problems are resolved. The rest of the
TIP is just not there; it needs specifications for all the critical
pieces, not just some of them.

I see from the change history of the TIP that nothing has happened on
this TIP since 2006, so I question whether it is worth the risk delaying
for it. I also don't feel like working on it myself at this stage; if it
just comes down to me, I'll go ahead with plain #257 since we know
that's in a good state implementation-wise (TclOO, which can be used as
an exemplar since it has limited scope and ambition) and pretty-much
completely written up.

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