Vasiljevic Zoran wrote:
>  The TIP 279 is functionally complete.

No. There is no complete definition of its oo::alias command (e.g. how 
does the target know what the object it is operating on is? Does the 
mechanism allow for target implementation commands written in C?)

>  Implementation is ready.  It is the 1.6.0 XOTcl itself.

Ah, but XOTcl does a lot more than the TIP specifies. Ergo, it can only
serve as a proof of concept and not as a reference implementation. For
example, #279 makes no mention of assertions yet there is plenty of
XOTcl code to deal with them. That is but one example. Also, even if we
restrict ourselves to the things actually discussed in the TIP, there is
no definition at all of oo::my, oo::self, oo::next, alloc, dealloc,
instproc, instforward, or info. There are some examples, but examples
are non-normative.

The TIP is incomplete. XOTcl 1.6.0 is (well, presumably, because the
incompleteness makes it impossible to be 100% sure) a large superset of
the functionality described within the TIP. Is that a TIP that's ready
to be voted upon? The TIP even explicitly states that XOTcl is a proof
of concept for critical parts, and would need to be rewritten! Who would
do the rewriting? (Getting a dispatcher right takes significant effort.)

>  Some say: it is complicated. I say: make it less (complicated).
>  Other say: code isn't adhering Tcl coding style. I say: reformat.

I say: call me when you're done. :-)

>  Really, those are by far the most objections I hear. And this can
>  be taken care of... The simpler (TIP257) syntax can be (and IS)
>  layered on top of the XOTcl dispatcher. The XOTcl must be reformatted
>  to follow the Tcl code style (this I do not consider a show-stopper).
>  
>  Honestly, if just the coding style is preventing people to consider  
>  TIP279
>  seriously, then I volunteer to reformat it, provided package maintainers
>  allow me to.

The formatting is not the largest issue. It's just an annoying roadblock
on the way. The things XOTcl does with the stack, they're a much larger
issue. TclOO solves those.

>  It is a win-win situation.

I admit that getting someone else to maintain your code is a good way to
win from your perspective.

>  OTOH, the TIP257 is experimental work w/o field "experience" in a real- 
>  world
>  applications. And I'm talking about mission-critical professional apps.

And you're trying to kick up enough fuss that it never gets that far?
Fie for shame!

>  A. On one side we have a 10+ years of experience and expertise plus  
>  code that works
>  great in complex and demanding installations and (at least 1)  
>  commercial product.

So why haven't more people adopted it? If we count production
installations, it's got to be iTcl that wins.

>  B. On the other side we have an experimental work (stripped-down A.)  
>  which needs
>  years(?) to stabilize in terms of API(s) and overall stability.

But which is lighter-weight, simpler, faster, and supports modes of
usage beyond that which A does? (It also passes some reasonable stress
tests rather well.)

>  I hope I did not offend you or anybody involved. If yes, I do  
>  apologize sincerely.

That's OK. I'm irritated anyway, especially by anyone supporting #279
without having read the source code to the proposed implementation.

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