Hi Gustaf,

Thanks for the detailed comments.
> > XOTcl has a bunch of great ideas BUT:
> > - While the rest of the world talks about methods/operations, 
> > attributes/fields and properties, XOTcl invents the terms instproc, 
> > instvar, and parameter/slot.   
>  for other situations as well, e.g. instmixins). Since about two years, 
>  one can
>  call methods in XOTcl as well as "method", no need for "instproc".
The XOTcl tutorial
(http://media.wu-wien.ac.at/doc/tutorial.html#class_methods) and
Language Reference (http://media.wu-wien.ac.at/doc/langRef-xotcl.html)
both use the term method quite liberally, but the syntax is "instproc".
I see no indication that you can say "myclass method do_something {args}
{...}", unless this documentation is out of date.
>  The term "slot" used in XOTcl is different to the terms used above. Slots
>  are objects managing data-items (e.g. attributes) and provide an 
>  appropriate
Yes, I misunderstood this.  Which of course proves in my mind that XOTcl
is not straightforward and unsurprising enough to be the core OO system ;/
Please understand that I'm not dissing XOTcl here.  I'm saying that as
someone with programming experience in C++, Delphi, Perl, Java and Tcl
(amongst others) I find XOTcl extensive, complex and (in parts)
surprising, and that I don't feel comfortable with the basics after a
couple of hours of investigation.  That in my mind makes it a poor
choice for a core OO system (as it stands).
> > - Functionality like filters and pre/post-conditions, even parameter 
> > rewriting in forward, belongs in Tcl as a whole, not just the OO 
> > extension.  This is also the "heavyweight" bit that doesn't belong in 
> > the Tcl core.   
>  Is the argument, that since all these features should be implemented 
>  for tcl
>  functions as well, these should not be provided in an core OO 
>  implementation
>  for tcl as well?
Umm ... a picture is worth a thousand words, hopefully bullet point
examples are worth a couple of hundred:
(by "core Tcl" I'm indicating the functionality in 8.5 - i.e. everything
as it stands, excluding OO)

(a) No filters in core Tcl or in core OO: acceptable
(b) No filters in core Tcl but filters in core OO: bad.  at some point
we'll want filters in core Tcl but then they syntax will almost
certainly be different, so then it's like your working with two
different languages.
(c) Filters in core Tcl and filters in core OO: good, assuming the
syntax looks & feels the same.
>  btw, TclOO supports "filters" as "advanced OO features", which are 
>  (citing tip257)
>  ".. constraints (implemented in Tcl code, naturally) on whether a 
>  method may be called."
Yes, and I don't think they should be in the core OO system.
> > (5) What's wrong with TclOO?
> > - It needs to specify variable/state behaviour.  Before release.  
>  actually, the discussion is not about "release" (TclOO 0.2 was 
>  released not long ago).
>  Its about adding something to the core.
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.
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.
>  His argument was: you should exactly know what you do, before you make 
>  other
>  things rely on it. He was even sceptic that floating point numbers 
>  should go into
>  hardware (around 1995). Once people rely on a behavior, it produces 
>  costs, if it
>  changes. Even worse, if it turns out to be conceptually flawn.
Yes, this is my point, although you state it somewhat better ;)
>  My current top 5 wrong things which are wrong with tcloo are:
I agree with most of these points.
>  - most probably lost important dynamic aspects of XOTcl (e.g. reclassing,
>    recreation semantics)
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.  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.
- 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.
- Some sort of support for widget creation
>  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.
>  For (a) tcloo is not the best choice, since it cloned already many bells
>  and whistles from XOTcl in some way. For (b), a downstripped XOTcl
>  would be the simplest option, for (c) TIP #279 is where to go
>  (could also help with a simple base language in (a), or goal (b)),
>  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 ;/

Regards,
Trevor




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