Donal,

On May 27, 2008, at 3:45 AM, Donal K. Fellows wrote:
>  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...)

Not to worry. :-)

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

In other e-mail on this list, I discussed this with Arnulf; he's got a  
working implementation for Itcl-ng.  Snit variables are (so far as I  
can see) equivalent to Itcl-ng "protected" variables.  Instance  
variables appear with unqualified names unless there's a conflict, in  
which case they are qualified by the namespace of the class in which  
they are defined.  It seems reasonable to me that Snit and Itcl should  
work the same way in this regard.

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

They certainly should be.  "Submethods", as you call them, are no  
different than regular methods except in how they are called.  As an  
example from Tk, the text widget has a "tag add" method.  It could  
have been implemented as "tag_add" instead, but making "tag" a  
subcommand with its own subcommands makes the set of text widget  
methods easier to document, to understand, and to use.  Snit  
submethods are the same way.  But this is really syntactic sugar, as  
one could express the same functionality with a single set of non- 
hierarchical subcommands.  It's just really good, tasty, sugar. :-)

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

Especially in 8.5, where dispatch is handled via "namespace ensemble".
Credit where it is due. :-)

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

That's indeed cool, though I'd need to roll in support for Snit's  
"delegate typemethod *" functionality.

Good stuff!

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