On Tuesday 14 August 2001 04:10, you wrote:
this is more or less what we have currently scheduled for 0.86 used as result for [self next] and [.. procsearch ....]. actually, having another order, such it has the same order as in the definition.
{b foo3 proc} {B instproc foo1} {A instproc foo2}
however, it would be still nicer to have methods as objects.
{m1 m2 m3}
[m1 class] -> Proc [m2 class] -> Instproc [m3 name] -> foo2
this would allow more methods on procs/instprocs and this is extensible with more metadata (e.g. pre/post conditions, c-code vs. tcl-code -> getting rid of the distinction of instcommand vs. instprocs ....).
Another interesting idea is to use aggregations for methods.
Class C C proc f {} {...} C instproc m {} {...}
would lead to C::f C::m where C::f amd C::m being of class Proc or Instproc
one could even use
Class C Proc C::f {} {...} Instproc C::m {} {....}
In the most straightforward case, this would exclude having instproc and procs of the same name, which is not great (OTH, other OO languages do not allow these either)... the cool part is that it is very easy to find out, where the command is defined, and moving, renaming etc. could work with the standard move/rename etc. methods, and "info procs" is not much more than a specialized "info children"....the long list of things in "info info" can be reduce....
but there are as well many arguments against it. one thing is memory consumption. to even think about it, we should find a way of defining lightweight objects....
I think it is a general problem of XOTcl. It is based on Tcl. Tcl is string oriented. We say everything is the list (string). Also internal interpreter interface (Tcl_Obj) is based on this principle. So internal object can be converted to string and we can build internal objects from string. XOTcl objects are based on so called handlers principle. Therefore XOTcl can not offer so complete (ger. durchgängig) language principle. everything is an object (see Smalltalk). That is not so tragic. I think the importest thing is to get good mix between list and object-oriented world.
The lightweigh objects are very important for such think as interface to other languages (C++). The possible solution (see my maligns to garbage collection) is to make XOTcl also internal really Tcl objects. This is hardly possible with actual Tcl interpreter. The second thing is that XOTcl will become another incompatible to early version language.
So I am very anxious on next development of XOTcl "(we have a mostly working SWIG bindig for xotcl)" that will be cool
Artur Trzewik