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