From: Will Duquette Date: May 5, 2004 5:15:44 PM PDT To: snit@lists.wjduquette.com Subject: Snit Reconsidered #3: Runtime Dependence This is the third in a series of short essays I'm going to be writing about the design and implementation of Snit in preparation for the implementation of Snit 1.0. One of the current properties of Snit is the Snit package itself is only required at the time your snit::types or snit::widgets are defined. Snit reads the snit::type or snit::widget definition, and "compiles" into Tcl code that implements your type but does not, in itself, require the Snit package. [*] I did it that way to encourage extension developers to use Snit--it's easy enough to hack snit.tcl just a bit, capture the "compiled" code, and include it in your extension. That way you get the benefits of Snit without worrying about whether users of your extension will have it installed. The trouble is, this approach means that a great deal of code is duplicated in memory at runtime for every snit::type and snit::widget. This is a waste of memory, obviously, because the duplicated code could easily be a part of the Snit package itself, and be shared at runtime by all snit::types and snit::widgets. In Snit 1.0 I propose to migrate as much of this code as I can out of the generated code and into the Snit package. The result will be lower memory consumption if you're using multiple Snit types or widgets, and quite possibly faster start-up, since Snit will be generating (and evaluating) less code for each type/widget. ----------- * Actually, that's a bit of a lie; the code that implements the "info" methods has been living in the snit:: namespace for a while now. I'm really just finishing the job. ------------------------------------------------------------- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com | The View from the Foothills