[Xotcl] TIP #257: Object Orientation for Tcl

[Donal K. Fellows]

Gustaf Neumann wrote:
> a) a more radical approach is to move all c-level commands out of
>      object and class into one or more method repositories (similar to
>      namespaces, but just a hash table containing for commands) and
>      let the object system designer link these (private/public, if
>      necessary) into the  base classes of an object system. One can
>      design a SnitClass or an XOTcl class or lsay a Java-kind class
>      quite freely, and it provides room for incremental improvement
>      without harming others.

The TIP is (totally!) light on C-level API, largely because I've no idea
what needs to go there. I'd even be happy (personally speaking) with an
OO system that did not provide any C-level API at all. Other people will
probably disagree. :-D

> b) We have discussed splitting xotcl classes into smaller components
>      about two years ago. We did not do this mostly since xotcl users
>      would most likely use Obect and Class as it is today.
[...]
>      Having said this, i am certainly not sure that "define" leads
>      the right way by moving the methods to manipulate the MR
>      to the top.

Having the metadata manipulators outside the primary object hierarchy is
pretty much a requirement, and it comes from what's needed for
supporting multiple OO "looks and feels" on top. Whether it is a single
command is quite negotiable as is the precise name of the command(s) of
course.

> c) the concern with "clean interfaces" is certainly valid but addresses
>    not only  the number of  methods, but as well orthogonality
>    (so, define is neither orthogonal with tcl or xotcl).

I admit it; I don't treat orthogonality as holy. It's nice, but it's not
the only goal I have. :-)

[...]
>    The TIP writers did not like the fact that general functionality
>    is introduced in xotcl from Object (as it is in Ruby or Smalltalk
>    or many other OO languages).  I never found this a problem
>    in real applications. i rather see problems with some low-level
>    stuff, when it is not this way, when classes are destroyed, objects
>    are reclassed, etc. I would feel better, when Object, Class are
>    xtocl-like and and we provide some protection schemes through
>    subclasses.

Again, that's driven by supporting other OO systems too.

> I am not going to repeat all earlier discussions here. Is it OK to
> send improvement proposals for the current TIP here, leaving
> aside this bigger issues?

The best place to discuss things is really the tcl-core mailing list.

BTW, I was wondering what happens when you do this in XOTcl (ignoring
the syntax for now):

   class A derived from Object
      defines instproc foo
   class B derived from A
      defines instproc bar
   class C derived from Object
      defines instprocs foo, bar and move

   object D is a C with B mixed in
      call: D foo
      call: D move

Which implementation of foo gets called first? Which implementation of
move gets called first?

Donal.