[Xotcl] TIP #257: Object Orientation for Tcl

[Gustaf Neumann]

Will Duquette schrieb:

>
>>
>> OK. The essential thing being done here then is to break down the  
>> grab-bag of methods defined in Class and Object into a bunch of  
>> different interfaces, so that clients of an object don't have to  
>> worry about a bunch of extra "proc" and "filter" etc methods that  
>> have nothing to do with their problem domain.  I can sympathise  with 
>> that.  However, I'm not sure [define] is the right solution,  as it 
>> just creates another bag of methods elsewhere (somewhat like  [info] 
>> has become).  We could simply change the methods to be class- methods 
>> of [class] and [object] (i.e. procs that expect an explicit  self 
>> argument, rather than instance-methods).  That way by default  
>> objects don't get lots of public methods that aren't needed by  
>> clients, but you can still do, e.g.:
>
First of all, i do not like having define as it is for various reasons. 
But having define as
an extra command is for an xotcl person not such a horrible thing, as 
long we have
(inst)forward, which can bring it back into business with a one-liner. 
The other way
around is more complicated.

But still, i think this issue is more than a matter of taste:
here are a few arguments:

 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.

 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.

      Roughly and abstractly speaking, an xotcl class differs from
      an xotcl object by
       - providing a method repository (MR) for its instances
       - providing a life cycle management (LCM, factory with recycling) 
for
         its instances (create, alloc, configure, init, recreate, 
destroy, dealloc)

      An xotcl object contains a data repository (DR) with an optional 
(from the
      implementation point of view) method repository for itself. 
Furthermore,
      objects are commands (which is to some respect nice, but makes it
      very hard to compete in speed with languages which have more
      lightweight objects such as Java).

      A simplified picture of xotcl looks as follows:

         XOTclObject = Cmd + DR + MR(self)
         XOTclClass = XOTclObject + LCM + MR(instances)

      With mixins, a class can have multiple MRs for its instances, and
      an object can have multiple MRs for self.

      Through various recent TIPs,  Tcl namespaces are
      converging towards xotcl Objects. As Tcl provides data repositories
      both through namespaces and arrays. I would like to see a
      convergence here, providing
      maybe multiple "views" to the same "data model" (in the MVC
      terminology), allowing e.g. "array names" on namespaces/objects
      or the data store methods (e.g. set, unset, trace, ...) as
      overloadable methods on associative
      arrays and to provide a uniform interface for defining
      procs/methods/instprocs..., not having to use sometimes "proc",
      other times "define method". This issue of having slim
      interfaces continues certainly on the C level where different
      implementation for this isses bloat the code and makes it hard for the
      code to behave consistently.

      Furthermore the bunch of info commands can
      be reduced by specifying in the info command the MR explicitely
      (using e.g. MR(method)), using e.g. one "info args", one rename
      method etc. for all methods/procs/instprocs/commands.

      It would be certainly interesting to have the aspects described 
above 
      as first class entities on the tcl layer and to provide composition
      functionalities for these similar to mixins for system designers.

      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.

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). Providing
    a smaller interface can be achieved through good composition
    facilities (having the "right" superclasses, mixins) and
    hiding/protection (don't show helper methods, define explicit
    interfaces, making methods/variables private).

    From earlier discussion about this TIP, i had the impression
    that this discussion is as well about "system matters" vs.
    "application matters".
    when one introspects an object, to see application issues
    (like submit, book, ...) rather than implementation nissues like
    being able to lappend to
    variables, etc. The point of view depends certainly on where
    one is doing the introspection, on the object (info methods is
    large) or on the class of the object with it instprocs. The
    documentation will be in most cases more on the class than
    on the object level, which will be a rather slick interface.

    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.

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?

-gustaf