Donal K. Fellows schrieb:
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
i was not talking about the c api at all here. i was refering to the xotcl methods implemented in C (e.g. create, destroy, class, forward, mixin ...) being placed into a method repository (e.g. a namespace) maybe called ::xotcl::objcmds and ::xotcl::classcmds and then one can do e.g.
oo::class ::xotcl::Object -import public ::xotcl::objcmds::* oo::class ::xotcl::Class -superclass ::xotcl::Object -import public ::xotcl::classcmds::* ::xotcl::Class class ::xotcl::Object
while people proposing other OO-Systems can import stuff private/public to any kind of class hierarchy they want. In reality this will be more complicated, but you get the idea.
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.
hmm, what is a metadata manipulator? i was talking about more primitive c-level constructs which could help to make tcl (and its oo parts) more consistent. Read method repository (MR) as hash table of command pointer and data repository (DR) as hash table of variables. i would like to see a consitent interface to these as well in ca on the tcl layer and having these compontents in a better composable way. This would provide a much better basis for multiple OOs and a better integration with current tcl core (both ways)
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.
This can be solved by defining e.g. SnitClass having everything private except what it wants to publish.
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.
i have to figure out, where this is...
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?
as kristoffer pointed out, there is only one move, so there is no ambiguity. In general the precedence order is per-object-mixins per-class-mixins self-procs class-hierarchy
The introspection command for this is D info precedence
-gustaf
Donal.