Sorry for not responding to this sooner; it hit my spam trap. (One of
the joys of moving to a new machine is retraining the filters...)

Will Duquette wrote:
>  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.

I'd be inclined to handle that by linking instance variables with the
same name to the class variables. I believe that [upvar] can do that.

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

This is problematic, but it's a tricky problem. It's possible to work
around it by having the name at the namespace level be derived from the
script-level name and the name of the class that declared it, with the
accessor methods and introspectors hiding this. I'm not so sure to what
extent this is a good idea (or amenable to fast implementation) though.

>  [Snit-like submethods] would be *extremely* cool.

Just checking: are submethods inheritable? If not, fast implementations
are easy, but if they are, it'll be trickier. (OTOH, it would have other
good properties which might justify the extra trickiness.)

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

I've done a little experimentation, and I find that I can do inheritable
megawidgets (the code is on the wiki) that work a lot like Tk widgets.
In testing, I find that the megawidget-wrapped ttk::button spins a
create-destroy loop at about a third of the speed of the underlying
widget (9.6k/sec vs. 29.2k/sec). I don't know where the costs are in
this at the moment; I've not profiled the code.

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

Having looked at the speed of Snit relatively recently, I think I
concur. Instantiation is painful (though dispatch is nice and fast).

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

I find that that's easy to deal with through an unknown-method handler
on the class object. I use this:

     method unknown {args} {
	if {[string match .* [lindex $args 0]]} {
	    return [uplevel 1 [list [self] create {*}$args]]
	}
	next {*}$args
     }

Donal.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core