Donal,

On May 4, 2008, at 5:06 PM, Donal K. Fellows wrote:
> > IIRC, the big challenges were these:
> > * Relationship between types and their instances
> 
>  I don't currently understand this comment.

The particular problem that comes to mind is that Snit methods can  
automatically see both type variables and instance variables without  
declaration.  What the precise issue was with this I don't recall, but  
I seem to recall that there was
something.

> > * Automatic declaration of type and instance variables in  
> > typemethod and
> >   method bodies
> 
>  By this you mean making available all variables defined in an instance
>  to every method invoked upon that instance, wherever it is defined?  
>  I've
>  done that in the past (e.g. a few years ago when I gave a talk on new
>  elemental features of 8.5) but I've found it's a problem when scaled  
>  up
>  as you easily get clashes between formal parameters to methods on a
>  class and variables defined on a sub(sub)class or instance. Explicit
>  naming of vars is both more like a normal procedure, and far less
>  inclined to blow up at unexpected times because of this problem.
> 
>  But don't take this as meaning that I'm against tackling this; it's
>  rather something I've largely punted up to now. :-)

I agree that name collisions are an issue when you add inheritance  
into the mix.  On the other hand, I hate explicit naming of vars,  
which is why Snit doesn't work that way.  A reasonable compromise  
would be that instance variables declared by a type would be  
automatically visible in the methods defined explicitly by that type,  
but not elsewhere, i.e., you'd need to explicitly declare them in  
subclasses.

In fact....my druthers would be that instance variables are completely  
private, unless a subclass explicitly says, I want this variable from  
my parent.  In this way, changes to a parent class would never cause a  
problem in child code.

However, as I understand it an object is in some sense just a  
namespace with methods attached, where the methods might be defined in  
an ancestor or mixin as well as in the type at hand.

This strikes me as somewhat problematic.  If a mixin class uses  
instance variable foo, and the class into which it is mixed also uses  
instance variable foo, but in a different way, won't they conflict?

> > * Support for hierarchical methods (i.e., methods which are  
> > themselves
> >   ensembles) (Something I use *all* the time)
> 
>  Would require a new method type, but not fundamentally difficult to  
>  add
>  and should be simpler than 8.5's ensembles due to fine differences in
>  the argument processing model.

That would be *extremely* cool.
> 
> > * Support for instance and widget options
> > * Support for building widgets
> 
>  Areas I punted. :-)

Yup.  Also places where there's a lot of Tcl code in the Snit  
implementation, slowing everything down, alas.

>  [Things needed:]
> > * The resulting implementation needed to be much faster than Snit  
> > 2.2.
> 
>  It really depends on what you mean. I expect to be able to beat  
>  dispatch
>  speeds and creation speeds, but perhaps not with the current code.  
>  (It's
>  still not fast enough for me, but I suppose I'm demanding that way...)

At the very least Snit needs to be no slower on TclOO, precisely in  
terms if dispatch, creation speeds, and like that.  That was one of  
the arguments for writing TclOO to begin with, that it would make  
packages like Snit "faster", for some definition of "faster".  Talking  
with Damon Courtenay in New Orleans last October, I believe what  
really bothered him was the speed of widget creation.

> > * The resulting implementation needed to be interoperable with plain
> >   vanilla TclOO objects (i.e., in terms of inheritance and so forth)
> 
>  I don't see why that wouldn't be the case. But it's late in the  
>  evening
>  right now so I may miss a lot of stuff. :-)

The particular thing that comes to mind was some of the magic that  
Snit does at instance/widget creation time.  I call the user's  
constructor wrapped in some other things, and I couldn't figure out  
how to do that without adding a stack level that would prevent the  
user's constructor from supporting TclOO method chaining like a real  
TclOO constructor.  Though perhaps I missed something; as you say,  
bootstrapping is dirty and confusing, and my mind kept boggling while  
I was working on this.
> 
> > * 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.
> 
>  That's the tricky bit. Or rather, it's probably tricky if 100%  
>  compat is required but a large island of compatibility may be easy  
>  to construct.

I suggested that at the time, and heard a horrendous groan from Jeff's  
direction.  I still don't see any option to abandoning 100%  
compatibility, though, not if you want to support interoperability.   
As I recall, some of the things I thought I'd need to do to get "as  
close as possible" to 100% would have run-time performance  
implications as well.

> > 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.
> 
>  I think the HEAD of TclOO is faster than previous versions of the code
>  (including, alas, the 0.2 release; I fixed a bug since then which
>  manifested as a substantive slowdown in some circumstances). There  
>  won't
>  be a big further benefit without improvements to memory management
>  (tricky) and probably some specific support code to make snit-like
>  operations efficient.

:-)

> > 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.
> 
>  I suspect that, for widgets at least, that's going to be tricky. So  
>  much
>  of a widget is encompassed by its creation, and mixing in for the sake
>  of it isn't a great pattern anyway. No way should we try to always
>  remove delegation; sometimes, it's exactly the right thing anyway.

Absolutely.

>  For general snit types, I'd need to look more carefully before  
>  commenting.
> 
> > Inheritance, etc.:  This should be possible, though again I saw  
> > issues
> > with constructors and Snit widgets.
> 
>  I can only address specifics (and then not always).

I mentioned one above; but I'd have to look at it in more detail to  
make it really specific. :-)

> > At base, here's what it comes down to:
> > * Should a TclOO-based Snit retain Snit 2 compatibility?
> 
>  IMO, as much as possible.

Without sacrificing significant functionality or performance.

> > * Would the result provide anything more than Snit 2?
> 
>  Dunno. :-)

Yup.  One of the reasons I've not yet gotten back to it.

> > * Can Widgets be done reasonably using the current framework?
> 
>  I've been meaning to have a look at this for some time. Keep not doing
>  so though...

One point: I've pretty much abandoned using type methods for Snit  
types that have instances; the fact that the "create" type method can  
be omitted is a real problem, because a misspelled typemethod becomes  
an unexpected instance.  However, this isn't a problem for widgets,  
because valid widget names don't collide with typical type method  
names.  Something to keep in mind, given that a TclOO widget type  
should be indistinguishable from a Tk widget to the programmer using it.

Will



> 
> 
>  Donal.
> 

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