[Xotcl] TIP #257: Object Orientation for Tcl

[Neil Madden]

Will Duquette wrote:
> The point of [define] is simply that we want to be able to
> create objects which have a limited set of subcommands.  Note
> that there's a distinct difference between writing an OO-API
> using a particular OO-framework for other users of that
> framework, and writing an object-style API for general users,
> many of whom might not care about the OO-framework at all.
> In the first case, you want to include all of the OO-framework's
> bells and whistles, because you expect your users to want to
> take advantage of them.  In the latter case, you want to keep
> the API simple, clean, and easily documented.

That's certainly a good goal.

> 
> [define] lets us do both.  With [define] "instproc" and its
> siblings aren't subcommands of our objects--but at the same time,
> "instproc" and its siblings are available to every user who
> cares about them.

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.:

class method myclass someproc {args} { ... }
object method myobj ...
object mixin myobj ...

This also somewhat reduces the need for self.method/method (or 
instproc/proc) distinction.  Likewise, you could also use it for the 
script-style of define:

class define myclass {
     method foo ...
     method bar ...
}

where these are interpreted as [class method myclass ...] and not 
[object method myclass ...].

It sort of clashes with previous XOTcl usage, where [class instproc] 
means define an instproc on the object "class", but if we change the 
name to "method" anyway then this is less of an issue.  You could even 
leave access to the methods using the form:

myclass class method someproc ...
myobj object method ...

which leaves only one top-level method in objects (two in classes). That 
seems a bit more OO-y, but I don't know if it really adds much.

-- Neil