[Xotcl] TIP #257: Object Orientation for Tcl

[Will Duquette]

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
>>>     http://www.tcl.tk/cgi-bin/tct/tip/257
>>> 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 http://www.cs.nott.ac.uk/~nem/newoo.txt .  
>> 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

-------------------------------------------------------------
        will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com | The View from the Foothills