Twylite schrieb:
>  (4) What's wrong with XOTcl?
>  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.
>    
actually no.

The term "instproc" was chosen by the OTcl folks, to distinguish between 
"proc"
(an object specific method, no available in many OO systems, but a 
straight foward
extension of procs in tcl namespaces) and methods defined in classes 
available for
the instances of the classes (therefore the prefix "inst", which is used 
consistently
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 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
place to store meta-data about attributes etc. For example, a 
persistency layer
can store there e.g. column names, types in SQL, one can provide
checker-functions there, default values, etc. etc (see e.g. xotcl-core 
in OpenACS).
>  - 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.
>    
i agree in principle, that such concepts would be great to have on every 
function.
But note, that getting the semantics right is much more complicated when 
inheritance
and mixins and other means of composition come into play. These semantics
interact heavily with the oo constructs (even forwarding, where you provide
on a class a forwarding rule for the instances).

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?

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

If this description is correct, then filters in TclOO are quite 
different from filters in
XOTcl. This would mean that filters in TclOO are more similar to "guards"
in XOTcl (e.g. filter guards, mixin guards).

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

Why is something added to the core? Because people want to rely on its 
behavior.
I remember a disscussion with Niklaus Wirth when i was at IBM research. 
It was
about his Lillith and about what should be in hardware and what should 
be in software.
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.

My current top 5 wrong things which are wrong with tcloo are:
 - no larger project ever used it
 - very slow adoption by the community
 - major argument in favor seems to be that it was implemented by a TCT
   member, who "stopped worrying and wrote the code" (i wonder
   what the reaction would have been, if some noname would have
   implemented it; we say in Austria: "mit der vollen Hose kann man leicht
   stinken")
 - no detailed comparison with xotcl but unproven claims that xotcl can 
run on top of it
 - many unknown properties
 - most probably lost important dynamic aspects of XOTcl (e.g. reclassing,
   recreation semantics)
 - apparently different mixin semantics, maybe no way to provode mixins for
   he class objects, many introspection subcommands missing (i don't 
actually know
   whether tcloo claims to have the same mixin semantics as xotcl (see 
e.g. various
   papers on www.xotcl.org) or whether it knows to have different mixin 
semantics,
   which should be documented)
 - sloppy oo terminology in the specification document or severe 
misconceptions
   about XOTcl.

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

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.

For my part, i am willing to work on (c) but i could certainly
concentrate on XOTcl, and port the good parts of my tip#279
implementation back into xotcl, try to get rid of its own stack, etc.
I see very little chance to build XOTcl on top of tcloo. As i
understood it, Will expressed that he sees no big benefits for snit
either, if he would base snit on tcloo.
>  (6) What to do?
>  (a) Implement TIP #131 instead.
>  (b) Failing which, I think the answer lies somewhere in between TclOO 
>  and XOTcl-minus-the-extra-bits (like filters, assertions, ...).  
>    
Since several people brought this up: i would not object against an 
xotcl in the core
without assertions. "instprocs" are only there for backward compatibility.
But without filters? Well even tclOO cloned XOTcl's filters.

Look for an exsample small language which is - i think - easy to learn 
based on TIP#279,
Section 3. for a simple language in 
http://media.wu-wien.ac.at/download/tcl-cool.tcl

-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