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.