Tomasz Kosiak schrieb:
>  >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.
>    
This was my impression as well. I am not sure, what has changed in tclOO
in this regard since then. I am not aware of any larger project
using tclOO, the number of releases of tclOO are very few compared
to the XOTcl developments.

The major difference between  TIP#257 and TIP#279
is that the first one provides a single OO flavor and the latter one 
provides an
OO framework, expressing the original goals of #257 to provide an 
implementational
basis for multiple OO languages.

As an exercise, i developed in Oct 2006 an itcl implementation on top of 
#279,
running e.g.  the protection regression tests of itcl without errors:

   % tclsh ~/scripts/callitcl.tcl ~/src/itcl3.3/tests/protection.test
   sourcing /Users/neumann/src/itcl3.3/tests/protection.test
   protection.test:        Total   60      Passed  60      Skipped 
0       Failed  0

Note that these tests include private/protected/public 
variables/methods/"commons".
If i remenber correctely, Arnulf mentioned in a mail to me, that he is 
using
my implemetation as well.

As another exercise, i implemented the tip#257 language on top of tip#279
in nov. 2006, and it passed most of its regression tests (68 passed, 15 
failed,
most (all?) due to different error messages, coming from the tcl backtrace
(one cannot hide the implementation from the tcl backtrace)). I stopped
at this point, since there are no applications needing the tip#257 language,
so the exercise is in practice useless.

And certainly, the 279 implementation runs full XOTcl.

The common oo framework idea of tip 279 has at least the following
benefits:

  - it allows a common code base in C
  - OO flavors (e.g. XOTcl) can continue to develop, the OO flavors
    can be implemented in Tcl or C
  - no other programming language (except maybe CLOS) offers
    such a flexibility to host multiple object systems in a common
    framework
>  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).
>  Please correct me if my understanding of the current situation is
>  somehow flawed.
>    
The tclOO developer made clear in the the heated discussions of the 8.5
inclusions that he has no interest in try to provide any kind of support for
XOTcl. Up to my knowledge there was no attempt to run e.g. a
part of the XOTcl regression test in the tclOO implementation.
>  I would liked TIP#279 authors and promoters to speak out how this
>  TIP#257 vs TIP#279 problem could be resolved.
>    
This is certainly a very important question that is not easy to answer.

In the heated 8.5 discussions i got the impression (maybe wrong)
that the tclOO camp has no interest in supporting XOTcl at all
(except cherry picking some XOTcl features). The lengthy mails i
had sent commenting earlier version got no response ("to busy
right now"), and i got as well the impression, that there was
nobody with a larger oo background devoted to the tclOO
project, trying to develop a next-generation OO system, but
rather following the argument: we need a simple oo system now.

One possible way to improve the situation could be as follows:
 a) we have to bring up the tip#279 implementation to the
     xotcl 1.6.0 level (e.g. var-reform, xotcl 1.6.0 generalizations)
     and finish the new generalized slot based interfaces
    (default value handling, method slots, etc.) and docment
    these in detail
 b) make a serious evaluation of the tip#279 implementation
    and reuese this/merge this into the code (afaik tclOO works
    only with tcl 8.5, using some newer interfaces not available
    in 8.4)

(a) should be possible by summer, i would appreciate that
someone from tcloo would cooperate for (b).

-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