Donal K. Fellows schrieb:
>  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? 
it knows the object from the invocation context.
>  Does the 
>  mechanism allow for target implementation commands written in C?)
>    
yes. One example is the Tcl "append" command. Or "set" can be used the 
same way.
>    
> > 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. 
why are you always poking on assertions. it is less the 400 lines of code.
we all agree that assertions are not so important for most people. I am
considering replacing assertions in XOTcl by more generic
method combinators, which would be a generic tool for assertions.
>  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 279 has to be made more concrete.
>  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! 
The tip #279 is referring to xotcl-1.5.3alpha2.tar.gz, which provides 
many options, that
xotcl 1.6.0 does not have. The tip#279 version is currently called 
branch 2.0.0 and resides
in git (git://alice.wu-wien.ac.at/xotcl). As mentioned in my 
collaboration offer, i do
not see this as finished for several reason.
> > 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. :-)
>    
Well, some of the code-wise bigger changes between xotcl 1.5.6 and xotcl 
1.6.0
were to follow the Tcl coding guidelines concerning e.g. variable names.
> 
>  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.
>    
Donal, you are getting somewhat unfair here.
Try to get TclOO running on Tcl 8.4.*, and i would wonder, what kind
of solution you would come up with as an extension writer.

Tcl 8.5 has a client data for callframes (which was silently added, at least
i don't remember a tip), something we have suggested
ages ago. XOTcl could (and should) certainly use this in the Tcl
8.5 environment. By using the new clientdata, the need for
xotcl's own stack and the required synchronizations for uplevels
etc. could be eliminated. On the bad side, this will drop Tcl 8.4
compatibility, which would not be good for many XOTcl users
out there.

> > 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? 
how widely was tcloo adoped in the last 2 years?

> > 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? 
such as? not sure, what you are comparing.

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

You seem to be well informed what Zoran reads or not.

-gustaf neumann


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