View · Search · Index
No registered users in community xowiki
in last 10 minutes

Re: [Xotcl] TIP #257: Object Orientation for Tcl

From: Donal K. Fellows <>
Date: Wed, 28 Sep 2005 16:49:01 +0100

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

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