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

[Xotcl] lightweight objects

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sat, 18 Aug 2001 08:51:29 +0200

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