Re: [TCLCORE] Use cases for objects

[Steve B. <st...@wo...>]

Hi Alex,

On 19/01/2012, at 12:02 AM, Donal K. Fellows wrote:

> On 18/01/2012 00:13, Alexander Shpilkin wrote:
>> I have been recently working on an object system for Jim based on the
>> new ensemble functionality[1]. So, I'd be glad to hear any use cases or
>> real-life experience of object-based design in Jim or Tcl programs, just
>> to have something to test the ideas on. Even examples of small class
>> (object? prototype?) hierarchies would be very useful.
> 
> Well, the canonical system of objects in Tcl is definitely Tk widgets.
> Not the relationships of the widgets to each other (that's composition)
> but rather the fact that you have classes, some idea of what operations
> all widgets have, etc. You can even think in terms of some widgets being
> derived from others; many buttons are really derived from labels (even
> if not explicitly) and spinbox is derived from entry. Ttk takes this a
> bit further.
> 
> Of course, that's not really a full OO system (deriving new classes is
> stupidly hard) and might not be exactly what you're after anyway.

I agree. Tk and related (Ttk, Snit, etc.) seem like the best examples
of a large OO system. I don't use Tcl for large systems, so I can't really
comment here.

> 
> Aside from that, most of Tcl's object-y things tend to be arranged in
> very shallow hierarchies. There are many things that ought to be classes
> in Tcllib, but not much inheritance to speak of. And there's the lesson
> of Snit: good delegation is often more important than good inheritance.

And again, I agree. tcllib seems to be a good example of things which
could/should be OO. URL handlers, perhaps udp vs tcp DNS transports,
the various data structure implementations, etc.

The one OO system currently in Jim Tcl is 'tree'. OO provides some nice
encapsulation here.

> 
>> The current version is a relatively simple prototype-based design with
>> more advanced features like multiple dispatch and traits added on top of
>> it.
> 
> Side note: I considered multiple dispatch for TclOO, but instead went
> for [proc]-like 'args' support as being more Tcl-ish. Can't really have
> both at the same time without the whole complicated business of a type
> system and… well… again, not Tcl-ish enough.
> 
> Jim may well have less of a problem with it. :-)
> 
>> Parts of it will probably be written in C, but the current pure-Tcl
>> implementation is already available at [2]. Thoughts and comments on any
>> aspects are very welcome, too. (There's at least one major problem in
>> it: objects never get garbage-collected, because a cyclic reference is
>> always created. Some features may not be complete.)
> 
> Dispatch, memory management and lifecycle management probably have to be
> written the hard way. (Full GC _is_ hard, which is why TclOO doesn't
> actually do it. Since TclOO objects are commands and not values though,
> that's not as hurtful as it might be. YMMV.)
> 
> Donal (this is all just my 2¢ and might not all be useful to you).

I had a look at the the code (https://gist.github.com/1617948) but it's
a bit hard to give constructive feedback without understanding better
what you are trying to achieve.

Can we have a document which describes the overall goal, especially
compared to alternatives?

Or at least some documentation for the public interface which it will
provide.

What is the model for statics? Lifetime? Access?

What you are doing certainly seems interesting, but
I'm not sure how it will be useful in the way in which I typically
use Jim Tcl.

Cheers,
Steve

--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au      P: +61 434 921 300
E: st...@wo...   F: +61 7 3391 6002