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