Donal,

You've not heard from me on this since New Orleans only because my  
life's
been full with other things; I still hope to get back to looking at Snit
and TclOO, but I'm not sure when it's going to happen.

That said, if you go to my blog, http://foothills.wjduquette.com/blog,
and search on "iGloo", you'll find the things I wrote when I was first
looking into building Snit on TclOO quite some time ago now.  I was
hampered at that point by having a pre-release build of both Tcl 8.5
*and* TclOO, both of which have matured a little since then, but I think
the comments I made at that time are still of interest.

(Please note: I present this more as a status report than as a critique
of TclOO; I'm certainly not arguing in favor of a "no" vote on the TIP.
On the contrary.  Also, all of the following discussion presumes that
Snit remains a pure-Tcl package.)

IIRC, the big challenges were these:

* Relationship between types and their instances
* Automatic declaration of type and instance variables in typemethod and
   method bodies
* Support for hierarchical methods (i.e., methods which are themselves
   ensembles) (Something I use *all* the time)
* Support for instance and widget options
* Support for building widgets

Clearly, I can implement all of these on top of TclOO in some manner.
To make it worth doing so, I felt at the time, at least one of the
following things needed to be true:

* The resulting implementation needed to be much faster than Snit 2.2.
* The resulting implementation needed to be interoperable with plain
   vanilla TclOO objects (i.e., in terms of inheritance and so forth)
* The resulting implementation gave Snit neat new features, such as
   true inheritance.

In addition, it would be best if legacy Snit code would work with the  
new
implementation with no changes.

As I recall, I had great difficulty seeing how to meet these goals.

Speed: At that time, method dispatch was on a par with "namespace
ensemble", which is used by Snit 2.2; and TclOO does nothing to speed up
option handling or widget creation.  I should revisit this, but until
TclOO is fully integrated and methods are "really efficient" I don't
think performance is a major argument for re-implementing Snit.

Interoperability with vanilla TclOO objects:  I couldn't see how to do
this AND retain full compatibility with existing Snit code.  This was
particularly an issue in the area of Snit widgets, where a lot of
interesting things go on at instance creation time, and the Snit code
didn't map well to what TclOO provides.  Again, by interoperability
I mean the ability to inherit from each other's classes.  I still think
that this is desirable; but I suspect that the difficulties involved in
doing so AND keeping compatibility with old code are insurmountable.

Inheritance, etc.:  This should be possible, though again I saw issues
with constructors and Snit widgets.

At base, here's what it comes down to:

* Should a TclOO-based Snit retain Snit 2 compatibility?
* Would the result provide anything more than Snit 2?
* Can Widgets be done reasonably using the current framework?

If the answer to the first question is "yes", I think the answer to
the second is probably "no", especially given my concerns about the
third.

Will

On May 4, 2008, at 7:13 AM, Donal K. Fellows wrote:
>  Hi everyone
> 
>  This is a warning that I think we're close to the point when I'll  
>  call a
>  vote on TIP#257, i.e. the merger of TclOO into Tcl. While it still has
>  its warts, they're largely implementation issues and we can sort them
>  out later (indeed, some may need full core integration to get  
>  completely
>  knocked on the head; it's difficult to really make methods efficient)
>  and the rest can get their own TIPs. But are there any really critical
>  problems left that can't be dealt with later? Hence this message.
> 
>  I'd like to remind people that TclOO strives for minimality in many
>  respects (I didn't want to get sucked into writing a class library!)  
>  and
>  it tries to leave state (i.e. variables) to conventional Tcl namespace
>  variables (slotted access could be built on top of this foundation,  
>  but
>  I'm not doing it at this stage). What it does do is provide a proper
>  inheritance model, mixins, filters, and mechanisms to allow things  
>  (new
>  method types, new data structures) to be plugged in from the C  
>  level. I
>  believe I've demonstrated that Self-like objects can be built on top,
>  and I think that something like both iTcl and XOTcl can work too (the
>  former wouldn't have actually worked with the proposal from 18 months
>  ago; the extra time allowed a number of key refinements of some  
>  internal
>  APIs). It's also being used already for building some of the reference
>  implementation of TDBC.
> 
>  In short, if there's a problem with TclOO, do speak up now!
> 
>  Donal.
> 
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save  
>  $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  Tcl-Core mailing list
>  Tcl-Core@[...].net
>  https://lists.sourceforge.net/lists/listinfo/tcl-core

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



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core