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

Re: [Xotcl] TIP #257: Object Orientation for Tcl

From: Will Duquette <>
Date: Mon, 26 Sep 2005 17:05:02 -0700

On Sep 26, 2005, at 1:36 PM, Kristoffer Lawson wrote:

>> Jeff Hobbs wrote:
>>> I know that many on this list will be interested in the
>>> following TIP just propsed:
>>> TIP #257: Object Orientation for Tcl
>>> This is indeed based on xotcl, but it is *not* xotcl. There
>>> are good reasons for this overall (but not necessarily for
>>> each individual change ;) ). I would like xotcl users who
>>> are interested to please read this TIP carefully, but to
>>> bear a few items in mind:
>> I feel slightly uneasy that debate about this TIP is occurring
>> here and on the wiki, and yet notification of its existence hasn't
>> even reached tcl-core yet. I have written some fairly substantial
>> notes on the TIP at .
>> These notes were supposed to be a post to tcl-core, but I don't
>> want to further pre-empt the TIP publication.

> Read through these commands. I probably agree on some points and
> disagree on others. I agree that the rationale behind [define] is
> fuzzy. I find the XOTcl model OK in that respect, but I don't have
> anything much against the TIP proposal either, and I do think it is
> a neat way of adding many methods in one go. Having syntax which
> attaches them to one another.

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.

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

It's really an aesthetic issue rather than a technical
issue; I find many OO APIs to be terribly cluttered (Java,
I'm looking at *you*) such that it becomes hard to tell
which methods are important amid all of the ones which
are only occasionally of interest.


        will -at- | Catch our weblog, | The View from the Foothills