File: snit.html

package info (click to toggle)
r-cran-tcltk2 1.2-10-1
links: PTS
area: main
in suites: jessie, jessie-kfreebsd
size: 5,356 kB
ctags: 1,386
sloc: tcl: 37,888; ansic: 792; python: 324; sh: 68; sed: 16; makefile: 1
file content (2524 lines) | stat: -rw-r--r-- 101,158 bytes
parent folder | download | duplicates (4)
<! -- -*- tcl -*- doctools manpage
   -->
<html><head>
<title>snit - Snit's Not Incr Tcl, OO system </title>
</head>
<! -- Generated from file './modules/snit/snit.man' by tcllib/doctools with format 'html'
   -->
<! -- Copyright &copy; 2003-2005, by William H. Duquette
   -->
<! -- CVS: $Id$ snit.n
   -->

<body>
<h1> snit(n) 1.0 snit &quot;Snit's Not Incr Tcl, OO system&quot;</h1>
<h2><a name="name">NAME</a></h2>
<p>
<p> snit - Snit's Not Incr Tcl





<h2><a name="table_of_contents">TABLE OF CONTENTS</a></h2>
<p>&nbsp;&nbsp;&nbsp;&nbsp;<a href="#table_of_contents">TABLE OF CONTENTS</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#synopsis">SYNOPSIS</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#description">DESCRIPTION</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#reference">REFERENCE</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#type_and_widget_definitions">Type and Widget Definitions</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#the_type_command">The Type Command</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#standard_type_methods">Standard Type Methods</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#the_instance_command">The Instance Command</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#standard_instance_methods">Standard Instance Methods</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#commands_for_use_in_object_code">Commands for use in Object Code</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#components_and_delegation">Components and Delegation</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#type_components_and_delegation">Type Components and Delegation</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#the_tk_option_database">The Tk Option Database</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#macros_and_meta-programming">Macros and Meta-programming</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#caveats">CAVEATS</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#known_bugs">KNOWN BUGS</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#history">HISTORY</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#credits">CREDITS</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#keywords">KEYWORDS</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#copyright">COPYRIGHT</a><br>
<h2><a name="synopsis">SYNOPSIS</a></h2>
<p>
package require <b>Tcl 8.4</b><br>
package require <b>snit ?1.0?</b><br>
<br><table border=1 width=100% cellspacing=0 cellpadding=0><tr            bgcolor=lightyellow><td bgcolor=lightyellow><table 0 width=100% cellspacing=0 cellpadding=0><tr valign=top ><td ><a href="#1"><b class='cmd'>snit::type</b> <i class='arg'>name</i> <i class='arg'>definition</i></a></td></tr>
<tr valign=top ><td ><a href="#2"><b class='cmd'>typevariable</b> <i class='arg'>name</i> ?<strong>-array</strong>? ?<i class='arg'>value</i>?</a></td></tr>
<tr valign=top ><td ><a href="#3"><b class='cmd'>typemethod</b> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#4"><b class='cmd'>typeconstructor</b> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#5"><b class='cmd'>variable</b> <i class='arg'>name</i> ?<strong>-array</strong>? ?<i class='arg'>value</i>?</a></td></tr>
<tr valign=top ><td ><a href="#6"><b class='cmd'>method</b> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#7"><b class='cmd'>option</b> <i class='arg'>namespec</i> ?<i class='arg'>defaultValue</i>?</a></td></tr>
<tr valign=top ><td ><a href="#8"><b class='cmd'>option</b> <i class='arg'>namespec</i> ?<i class='arg'>options...</i>?</a></td></tr>
<tr valign=top ><td ><a href="#9"><b class='cmd'>constructor</b> <i class='arg'>arglist</i> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#10"><b class='cmd'>destructor</b> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#11"><b class='cmd'>proc</b> <i class='arg'>name</i> <i class='arg'>args</i> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#12"><b class='cmd'>delegate</b> <strong>method</strong> <i class='arg'>name</i> <strong>to</strong> <i class='arg'>comp</i> ?<strong>as</strong> <i class='arg'>target</i>?</a></td></tr>
<tr valign=top ><td ><a href="#13"><b class='cmd'>delegate</b> <strong>method</strong> <i class='arg'>name</i> ?<strong>to</strong> <i class='arg'>comp</i>? <strong>using</strong> <i class='arg'>pattern</i></a></td></tr>
<tr valign=top ><td ><a href="#14"><b class='cmd'>delegate</b> <strong>method</strong> <strong>*</strong> ?<strong>to</strong> <i class='arg'>comp</i>? ?<strong>using</strong> <i class='arg'>pattern</i>? ?<strong>except</strong> <i class='arg'>exceptions</i>?</a></td></tr>
<tr valign=top ><td ><a href="#15"><b class='cmd'>delegate</b> <strong>option</strong> <i class='arg'>namespec</i> <strong>to</strong> <i class='arg'>comp</i></a></td></tr>
<tr valign=top ><td ><a href="#16"><b class='cmd'>delegate</b> <strong>option</strong> <i class='arg'>namespec</i> <strong>to</strong> <i class='arg'>comp</i> <strong>as</strong> <i class='arg'>target</i></a></td></tr>
<tr valign=top ><td ><a href="#17"><b class='cmd'>delegate</b> <strong>option</strong> <strong>*</strong> <strong>to</strong> <i class='arg'>comp</i></a></td></tr>
<tr valign=top ><td ><a href="#18"><b class='cmd'>delegate</b> <strong>option</strong> <strong>*</strong> <strong>to</strong> <i class='arg'>comp</i> <strong>except</strong> <i class='arg'>exceptions</i></a></td></tr>
<tr valign=top ><td ><a href="#19"><b class='cmd'>component</b> <i class='arg'>comp</i> ?<strong>-public</strong> <i class='arg'>method</i>? ?<strong>-inherit</strong> <i class='arg'>flag</i>?</a></td></tr>
<tr valign=top ><td ><a href="#20"><b class='cmd'>delegate</b> <strong>typemethod</strong> <i class='arg'>name</i> <strong>to</strong> <i class='arg'>comp</i> ?<strong>as</strong> <i class='arg'>target</i>?</a></td></tr>
<tr valign=top ><td ><a href="#21"><b class='cmd'>delegate</b> <strong>typemethod</strong> <i class='arg'>name</i> ?<strong>to</strong> <i class='arg'>comp</i>? <strong>using</strong> <i class='arg'>pattern</i></a></td></tr>
<tr valign=top ><td ><a href="#22"><b class='cmd'>delegate</b> <strong>typemethod</strong> <strong>*</strong> ?<strong>to</strong> <i class='arg'>comp</i>? ?<strong>using</strong> <i class='arg'>pattern</i>? ?<strong>except</strong> <i class='arg'>exceptions</i>?</a></td></tr>
<tr valign=top ><td ><a href="#23"><b class='cmd'>typecomponent</b> <i class='arg'>comp</i> ?<strong>-public</strong> <i class='arg'>typemethod</i>? ?<strong>-inherit</strong> <i class='arg'>flag</i>?</a></td></tr>
<tr valign=top ><td ><a href="#24"><b class='cmd'>pragma</b> ?<i class='arg'>options...</i>?</a></td></tr>
<tr valign=top ><td ><a href="#25"><b class='cmd'>expose</b> <i class='arg'>comp</i></a></td></tr>
<tr valign=top ><td ><a href="#26"><b class='cmd'>expose</b> <i class='arg'>comp</i> <strong>as</strong> <i class='arg'>method</i></a></td></tr>
<tr valign=top ><td ><a href="#27"><b class='cmd'>onconfigure</b> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#28"><b class='cmd'>oncget</b> <i class='arg'>name</i> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#29"><b class='cmd'>snit::widget</b> <i class='arg'>name</i> <i class='arg'>definition</i></a></td></tr>
<tr valign=top ><td ><a href="#30"><b class='cmd'>widgetclass</b> <i class='arg'>name</i></a></td></tr>
<tr valign=top ><td ><a href="#31"><b class='cmd'>hulltype</b> <i class='arg'>type</i></a></td></tr>
<tr valign=top ><td ><a href="#32"><b class='cmd'>snit::widgetadaptor</b> <i class='arg'>name</i> <i class='arg'>definition</i></a></td></tr>
<tr valign=top ><td ><a href="#33"><b class='cmd'>snit::typemethod</b> <i class='arg'>type</i> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#34"><b class='cmd'>snit::method</b> <i class='arg'>type</i> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#35"><b class='cmd'>snit::macro</b> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#36"><b class='cmd'>snit::compile</b> <i class='arg'>which</i> <i class='arg'>type</i> <i class='arg'>body</i></a></td></tr>
<tr valign=top ><td ><a href="#37"><b class='cmd'>$type</b> <i class='arg'>typemethod</i> <i class='arg'>args</i>...</a></td></tr>
<tr valign=top ><td ><a href="#38"><b class='cmd'>$type</b> <strong>create</strong> <i class='arg'>name</i> ?<i class='arg'>option</i> <i class='arg'>value</i> ...?</a></td></tr>
<tr valign=top ><td ><a href="#39"><b class='cmd'>$type</b> <strong>info typevars</strong> ?<i class='arg'>pattern</i>?</a></td></tr>
<tr valign=top ><td ><a href="#40"><b class='cmd'>$type</b> <strong>info typemethods</strong> ?<i class='arg'>pattern</i>?</a></td></tr>
<tr valign=top ><td ><a href="#41"><b class='cmd'>$type</b> <strong>info instances</strong> ?<i class='arg'>pattern</i>?</a></td></tr>
<tr valign=top ><td ><a href="#42"><b class='cmd'>$type</b> <strong>destroy</strong></a></td></tr>
<tr valign=top ><td ><a href="#43"><b class='cmd'>$object</b> <i class='arg'>method</i> <i class='arg'>args...</i></a></td></tr>
<tr valign=top ><td ><a href="#44"><b class='cmd'>$object</b> <strong>configure</strong> ?<i class='arg'>option</i>? ?<i class='arg'>value</i>? ...</a></td></tr>
<tr valign=top ><td ><a href="#45"><b class='cmd'>$object</b> <strong>configurelist</strong> <i class='arg'>optionlist</i></a></td></tr>
<tr valign=top ><td ><a href="#46"><b class='cmd'>$object</b> <strong>cget</strong> <i class='arg'>option</i></a></td></tr>
<tr valign=top ><td ><a href="#47"><b class='cmd'>$object</b> <strong>destroy</strong></a></td></tr>
<tr valign=top ><td ><a href="#48"><b class='cmd'>$object</b> <strong>info type</strong></a></td></tr>
<tr valign=top ><td ><a href="#49"><b class='cmd'>$object</b> <strong>info vars</strong> ?<i class='arg'>pattern</i>?</a></td></tr>
<tr valign=top ><td ><a href="#50"><b class='cmd'>$object</b> <strong>info typevars</strong> ?<i class='arg'>pattern</i>?</a></td></tr>
<tr valign=top ><td ><a href="#51"><b class='cmd'>$object</b> <strong>info typemethods</strong> ?<i class='arg'>pattern</i>?</a></td></tr>
<tr valign=top ><td ><a href="#52"><b class='cmd'>$object</b> <strong>info options</strong> ?<i class='arg'>pattern</i>?</a></td></tr>
<tr valign=top ><td ><a href="#53"><b class='cmd'>$object</b> <strong>info methods</strong> ?<i class='arg'>pattern</i>?</a></td></tr>
<tr valign=top ><td ><a href="#54"><b class='cmd'>mymethod</b> <i class='arg'>name</i> ?<i class='arg'>args...</i>?</a></td></tr>
<tr valign=top ><td ><a href="#55"><b class='cmd'>mytypemethod</b> <i class='arg'>name</i> ?<i class='arg'>args...</i>?</a></td></tr>
<tr valign=top ><td ><a href="#56"><b class='cmd'>myproc</b> <i class='arg'>name</i> ?<i class='arg'>args...</i>?</a></td></tr>
<tr valign=top ><td ><a href="#57"><b class='cmd'>myvar</b> <i class='arg'>name</i></a></td></tr>
<tr valign=top ><td ><a href="#58"><b class='cmd'>mytypevar</b> <i class='arg'>name</i></a></td></tr>
<tr valign=top ><td ><a href="#59"><b class='cmd'>from</b> <i class='arg'>argvName</i> <i class='arg'>option</i> ?<i class='arg'>defvalue</i>?</a></td></tr>
<tr valign=top ><td ><a href="#60"><b class='cmd'>install</b> <i class='arg'>compName</i> <strong>using</strong> <i class='arg'>objType</i> <i class='arg'>objName</i> <i class='arg'>args...</i></a></td></tr>
<tr valign=top ><td ><a href="#61"><b class='cmd'>installhull</b> <strong>using</strong> <i class='arg'>widgetType</i> <i class='arg'>args...</i></a></td></tr>
<tr valign=top ><td ><a href="#62"><b class='cmd'>installhull</b> <i class='arg'>name</i></a></td></tr>
<tr valign=top ><td ><a href="#63"><b class='cmd'>variable</b> <i class='arg'>name</i></a></td></tr>
<tr valign=top ><td ><a href="#64"><b class='cmd'>typevariable</b> <i class='arg'>name</i></a></td></tr>
<tr valign=top ><td ><a href="#65"><b class='cmd'>varname</b> <i class='arg'>name</i></a></td></tr>
<tr valign=top ><td ><a href="#66"><b class='cmd'>typevarname</b> <i class='arg'>name</i></a></td></tr>
<tr valign=top ><td ><a href="#67"><b class='cmd'>codename</b> <i class='arg'>name</i></a></td></tr>
</table></td></tr></table>
<h2><a name="description">DESCRIPTION</a></h2>
<p>
<p>

Snit is a pure Tcl object and megawidget system.  It's
unique among Tcl object systems in that it's based not on inheritance
but on delegation.  Object systems based on inheritance only allow you
to inherit from classes defined using the same system, which is
limiting.  In Tcl, an object is 
anything that acts like an object; it shouldn't matter how the object
was implemented.  Snit is intended to help you build applications out of
the materials at hand; thus, Snit is designed to be able to
incorporate and build on any object, whether it's a hand-coded object,
a <strong>Tk</strong> widget, an <strong>Incr Tcl</strong> object,
a <strong>BWidget</strong> or almost anything else.

<p>

This man page is intended to be a reference only; see the accompanying
<b class='cmd'>snitfaq</b> for a gentler, more tutorial introduction to Snit
concepts.


<h2><a name="reference">REFERENCE</a></h2>
<p>

<h3><a name="type_and_widget_definitions">Type and Widget Definitions</a></h3>
<p>

Snit provides the following commands for defining new types:

<dl>

<dt><a name="1"><b class='cmd'>snit::type</b> <i class='arg'>name</i> <i class='arg'>definition</i></a><dd>


Defines a new abstract data type called <i class='arg'>name</i>.  If <i class='arg'>name</i> is
not a fully qualified command name, it is assumed to be a name in the
namespace in which the <b class='cmd'>snit::type</b> command was called (usually the
global namespace).  It returns the fully qualified name of the new type.

<br><br>

The type name is then a command that is used to create objects of the
new type, along with other activities.

<br><br>

The <b class='cmd'>snit::type</b> <i class='arg'>definition</i> block is a script that may
contain the following definitions:

<br><br>
<dl>
<dt><a name="2"><b class='cmd'>typevariable</b> <i class='arg'>name</i> ?<strong>-array</strong>? ?<i class='arg'>value</i>?</a><dd>


Defines a type variable with the specified <i class='arg'>name</i>, and optionally
the specified <i class='arg'>value</i>.  Type variables are shared by all instances
of the type.  If the <strong>-array</strong> option is included, then 
<i class='arg'>value</i> should be a list of keyword/value pairs; it will be
assigned to the variable in the manner of <b class='cmd'>array set</b>.

<br><br>
<dt><a name="3"><b class='cmd'>typemethod</b> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a><dd>


Defines a type method, a subcommand of the new type command,
 with the specified name, argument list, and
body.  The <i class='arg'>arglist</i> is a normal Tcl argument list and may contain
default arguments and the <strong>args</strong> argument; however, it may not
contain the argument names <strong>type</strong>, <strong>self</strong>, <strong>selfns</strong>, or
<strong>win</strong>.

<br><br>

The variable <strong>type</strong> is automatically defined in the <i class='arg'>body</i> to
the type's fully-qualified name.  In addition,
type variables are automatically visible in the <i class='arg'>body</i> 
of every type method.

<br><br>

If the <i class='arg'>name</i> consists of two or more tokens, Snit handles it specially:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    typemethod {a b} {} { ... }
</pre></td></tr></table></p>

The following two calls to this type method are equivalent:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    $type {a b}
    $type a b
</pre></td></tr></table></p>

In other words, <strong>a</strong> becomes a subcommand of <strong>$type</strong>, and
<strong>b</strong> becomes a subcommand of <strong>a</strong>.  This makes it possible
to define a hierarchical command structure; see <b class='cmd'>method</b>, below,
for more examples.

<br><br>
<dt><a name="4"><b class='cmd'>typeconstructor</b> <i class='arg'>body</i></a><dd>


The type constructor's <i class='arg'>body</i> is executed once when the
type is first defined; it is typically used to
initialize array-valued type variables and to add
entries to <a href="#the_tk_option_database">The Tk Option Database</a>.

<br><br>

The variable <strong>type</strong> is automatically defined in the <i class='arg'>body</i>, 
and contains the type's fully-qualified name.  In addition,
type variables are automatically visible in the <i class='arg'>body</i> of the type 
constructor.

<br><br>

A type may define at most one type constructor.

<br><br>
<dt><a name="5"><b class='cmd'>variable</b> <i class='arg'>name</i> ?<strong>-array</strong>? ?<i class='arg'>value</i>?</a><dd>


Defines an instance variable, a private variable associated with each
instance of this type, and optionally its initial value.  
If the <strong>-array</strong> option is included, then 
<i class='arg'>value</i> should be a list of keyword/value pairs; it will be
assigned to the variable in the manner of <b class='cmd'>array set</b>.

<br><br>
<dt><a name="6"><b class='cmd'>method</b> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a><dd>


Defines an instance method, a subcommand of each instance of this
type, with the specified name, argument list and body.
The <i class='arg'>arglist</i> is a normal Tcl argument list and may contain
default arguments and the <strong>args</strong> argument.  

<br><br>

The method is implicitly passed the following arguments as well:

<strong>type</strong>, which contains the fully-qualified type name; <strong>self</strong>,
which contains the current instance command name; <strong>selfns</strong>, which
contains the name of the instance's private namespace; and <strong>win</strong>,
which contains the original instance name.

Consequently, the <i class='arg'>arglist</i> may not contain the argument names
<strong>type</strong>, <strong>self</strong>, <strong>selfns</strong>, or <strong>win</strong>.

<br><br>

An instance method defined in this way is said to be
<em>locally defined</em>.

<br><br>

Type and instance variables are
automatically visible in all instance methods.  If the type has
locally defined options, the <strong>options</strong> array is also visible.

<br><br>

If the <i class='arg'>name</i> consists of two or more tokens, Snit handles it specially:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    method {a b} {} { ... }
</pre></td></tr></table></p>

The following two calls to this type method are equivalent:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    $self {a b}
    $self a b
</pre></td></tr></table></p>

In other words, <strong>a</strong> becomes a subcommand of <strong>$self</strong>, and
<strong>b</strong> becomes a subcommand of <strong>a</strong>.  This makes it possible
to define a hierarchical command structure.  For example,

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>% snit::type dog {
    method {tail wag}   {} {return &quot;Wag, wag&quot;}
    method {tail droop} {} {return &quot;Droop, droop&quot;}
}
::dog
% dog spot
::spot
% spot tail wag
Wag, wag
% spot tail droop
Droop, droop
%
</pre></td></tr></table></p>

What we've done is implicitly defined a &quot;tail&quot; method with subcommands
&quot;wag&quot; and &quot;droop&quot;.  Consequently, it's an error to define &quot;tail&quot;
explicitly.
       
<br><br>
<dt><a name="7"><b class='cmd'>option</b> <i class='arg'>namespec</i> ?<i class='arg'>defaultValue</i>?</a><dd>

<dt><a name="8"><b class='cmd'>option</b> <i class='arg'>namespec</i> ?<i class='arg'>options...</i>?</a><dd>


Defines an option for instances of this type, and optionally gives it
an initial value.  The initial value defaults to the empty string if
no <i class='arg'>defaultValue</i> is specified.

<br><br>

An option defined in this way is said to be <em>locally defined</em>.

<br><br>

The <i class='arg'>namespec</i> is a list defining the option's
name, resource name, and class name, e.g.:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option {-font font Font} {Courier 12}
</pre></td></tr></table></p>

The option name must begin with a hyphen, and must not contain any
upper case letters. The resource name and class name are optional; if
not specified, the resource name defaults to the option name, minus
the hyphen, and the class name defaults to the resource name with the
first letter capitalized.  Thus, the following statement is equivalent
to the previous example:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option -font {Courier 12}
</pre></td></tr></table></p>

See <a href="#the_tk_option_database">The Tk Option Database</a> for more information about
resource and class names.

<br><br>

Options are normally set and retrieved using the standard
instance methods <strong>configure</strong> and <strong>cget</strong>; within instance code
(method bodies, etc.), option values are available through the 
<strong>options</strong> array:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    set myfont $options(-font)
</pre></td></tr></table></p>

If the type defines any option handlers (e.g., <strong>-configuremethod</strong>), 
then it should probably use <strong>configure</strong> and <strong>cget</strong> to 
access its options to avoid subtle errors.

<br><br>

The <b class='cmd'>option</b> statement may include the following options:

<br><br>
<dl>
<dt><strong>-default</strong> <i class='arg'>defvalue</i><dd>

Defines the option's default value; the option's default value 
will be &quot;&quot; otherwise.

<br><br>
<dt><strong>-readonly</strong> <i class='arg'>flag</i><dd>

The <i class='arg'>flag</i> can be any Boolean value recognized by Tcl.  
If <i class='arg'>flag</i> is true, then the option is readonly--it can only
be set using <strong>configure</strong> or <strong>configurelist</strong> 
at creation time, i.e., in the type's constructor.

<br><br>
<dt><strong>-cgetmethod</strong> <i class='arg'>methodName</i><dd>

Every locally-defined option may define a <strong>-cgetmethod</strong>;
it is called when the option's value is retrieved using the
<strong>cget</strong> method.  Whatever the method's <i class='arg'>body</i> returns will
be the return value of the call to <strong>cget</strong>.  

<br><br>

The named method must take one argument, the option name.
For example, this code is equivalent to (though slower than)
Snit's default handling of <b class='cmd'>cget</b>:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option -font -cgetmethod GetOption
    method GetOption {option} {
        return $options($option)
    }
</pre></td></tr></table></p>

Note that it's possible for any number of options to share a 
<strong>-cgetmethod</strong>.

<br><br>
<dt><strong>-configuremethod</strong> <i class='arg'>methodName</i><dd>

Every locally-defined option may define a <strong>-configuremethod</strong>;
it is called when the option's value is set using the
<strong>configure</strong> or <strong>configurelist</strong> methods.  It is the
named method's responsibility to save the option's value; in other
words, the value will not be saved to the <strong>options()</strong> array unless
the method saves it there.

<br><br>

The named method must take two arguments, the option name and
its new value.  For example, this code is equivalent to 
(though slower than) Snit's default handling of <b class='cmd'>configure</b>:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option -font -configuremethod SetOption
    method SetOption {option value} {
        set options($option) $value
    }
</pre></td></tr></table></p>

Note that it's possible for any number of options to share a 
single <strong>-configuremethod</strong>.

<br><br>
<dt><strong>-validatemethod</strong> <i class='arg'>methodName</i><dd>

Every locally-defined option may define a <strong>-validatemethod</strong>;
it is called when the option's value is set using the
<strong>configure</strong> or <strong>configurelist</strong> methods, just before
the <strong>-configuremethod</strong> (if any).  It is the
named method's responsibility to validate the option's new value,
and to throw an error if the value is invalid.

<br><br>

The named method must take two arguments, the option name and
its new value.  For example, this code verifies that 
<strong>-flag</strong>'s value is a valid Boolean value:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option -font -validatemethod CheckBoolean
    method CheckBoolean {option value} {
        if {![string is boolean -strict $value]} {
            error &quot;option $option must have a boolean value.&quot;
        }
    }
</pre></td></tr></table></p>

Note that it's possible for any number of options to share a 
single <strong>-validatemethod</strong>.

</dl>

<dt><a name="9"><b class='cmd'>constructor</b> <i class='arg'>arglist</i> <i class='arg'>body</i></a><dd>


The constructor definition specifies a <i class='arg'>body</i> of code to be
executed when a new instance is created.  The <i class='arg'>arglist</i> is a 
normal Tcl argument list and may contain default arguments and 
the <strong>args</strong> argument.

<br><br>

As with methods, the arguments <strong>type</strong>, <strong>self</strong>, <strong>selfns</strong>, 
and <strong>win</strong> are defined implicitly, and all type and instance 
variables are automatically visible in its <i class='arg'>body</i>.

<br><br>

If the <i class='arg'>definition</i> doesn't explicitly define the constructor,
Snit defines one implicitly.  If the type declares at least one option
(whether locally or by delegation), the default constructor will 
be defined as follows:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    constructor {args} {
        $self configurelist $args
    }
</pre></td></tr></table></p>

For standard Tk widget behavior, the argument list should be 
the single name <strong>args</strong>, as shown.

<br><br>

If the <i class='arg'>definition</i> defines neither a constructor nor
any options, the default constructor is defined as follows:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    constructor {} {}
</pre></td></tr></table></p>

<br><br>
<dt><a name="10"><b class='cmd'>destructor</b> <i class='arg'>body</i></a><dd>


The destructor is used to code any actions that must take place when
an instance of the type is destroyed: typically, the destruction of
anything created in the constructor.

<br><br>

The destructor takes no explicit arguments; as with methods, the 
arguments <strong>type</strong>, <strong>self</strong>, <strong>selfns</strong>, and <strong>win</strong>, are 
defined implicitly, and all type and instance 
variables are automatically visible in its <i class='arg'>body</i>.

<br><br>
<dt><a name="11"><b class='cmd'>proc</b> <i class='arg'>name</i> <i class='arg'>args</i> <i class='arg'>body</i></a><dd>


Defines a new Tcl procedure in the type's namespace.

<br><br>

The defined proc differs from a normal Tcl proc in that all type
variables are automatically visible.  The proc can access 
instance variables as well, provided that it is passed
<strong>selfns</strong> (with precisely that name) as one of its arguments.

<br><br>

Although they are not implicitly defined for procs, the argument names
<strong>type</strong>, <strong>self</strong>, and <strong>win</strong> should be avoided.

<br><br>
<dt><a name="12"><b class='cmd'>delegate</b> <strong>method</strong> <i class='arg'>name</i> <strong>to</strong> <i class='arg'>comp</i> ?<strong>as</strong> <i class='arg'>target</i>?</a><dd>


Delegates method <i class='arg'>name</i> to component <i class='arg'>comp</i>.  That is, when
method <i class='arg'>name</i> is called on an instance of this type, the method
and its arguments will be passed to the named component's command
instead.  That is, the following statement

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    delegate method wag to tail
</pre></td></tr></table></p>

is roughly equivalent to this explicitly defined method:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    method wag {args} {
        uplevel $tail wag $args
    }
</pre></td></tr></table></p>

As with methods, the <i class='arg'>name</i> may have multiple tokens; in this
case, the last token of the name is assumed to be the name of the
component's method.

<br><br>

The optional <strong>as</strong> clause allows you to specify the delegated
method name and possibly add some arguments:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    delegate method wagtail to tail as &quot;wag briskly&quot;
</pre></td></tr></table></p>

<br><br>

A method cannot be both locally defined and delegated.

<br><br>

<strong>Note:</strong> All forms of <b class='cmd'>delegate method</b> can delegate to
both instance components and type components.

<br><br>
<dt><a name="13"><b class='cmd'>delegate</b> <strong>method</strong> <i class='arg'>name</i> ?<strong>to</strong> <i class='arg'>comp</i>? <strong>using</strong> <i class='arg'>pattern</i></a><dd>


In this form of the <b class='cmd'>delegate</b> statement, the <strong>using</strong> clause
is used to specify the precise form of the command to which method 
<i class='arg'>name</i> name is delegated.  In this form, the <strong>to</strong> clause is
optional, since the chosen command might not involve any particular
component.

<br><br>

The value of the <strong>using</strong> clause is a list that may contain 
any or all of the following substitution codes; these codes are
substituted with the described value to build the delegated command
prefix.  Note that the following two statements are equivalent:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    delegate method wag to tail
    delegate method wag to tail using &quot;%c %m&quot;
</pre></td></tr></table></p>

Each element of the list becomes a single element of the delegated
command--it is never reparsed as a string.

<br><br>

Substitutions:
<br><br>
<dl>
<dt><strong>%%</strong><dd>

This is replaced with a single &quot;%&quot;.  Thus, to pass the string &quot;%c&quot;
to the command as an argument, you'd write &quot;%%c&quot;.

<br><br>
<dt><strong>%c</strong><dd>

This is replaced with the named component's command.

<br><br>
<dt><strong>%m</strong><dd>

This is replaced with the final token of the method <i class='arg'>name</i>; if
the method <i class='arg'>name</i> has one token, this is identical to <strong>%M</strong>.

<br><br>
<dt><strong>%M</strong><dd>

This is replaced by the method <i class='arg'>name</i>; if the <i class='arg'>name</i> consists
of multiple tokens, they are joined by space characters.

<br><br>
<dt><strong>%j</strong><dd>

This is replaced by the method <i class='arg'>name</i>; if the <i class='arg'>name</i> consists
of multiple tokens, they are joined by underscores (&quot;_&quot;).

<br><br>
<dt><strong>%t</strong><dd>

This is replaced with the fully qualified type name.

<br><br>
<dt><strong>%n</strong><dd>

This is replaced with the name of the instance's private namespace.

<br><br>
<dt><strong>%s</strong><dd>

This is replaced with the name of the instance command.

<br><br>
<dt><strong>%w</strong><dd>

This is replaced with the original name of the instance command; for
Snit widgets and widget adaptors, it will be the Tk window name.
It remains constant, even if the instance command is renamed.

</dl>

<dt><a name="14"><b class='cmd'>delegate</b> <strong>method</strong> <strong>*</strong> ?<strong>to</strong> <i class='arg'>comp</i>? ?<strong>using</strong> <i class='arg'>pattern</i>? ?<strong>except</strong> <i class='arg'>exceptions</i>?</a><dd>


The form <b class='cmd'>delegate method *</b> delegates all unknown method names to the
specified <i class='arg'>comp</i>onent.  The <strong>except</strong> clause can be used to
specify a list of <i class='arg'>exceptions</i>, i.e., method names that will not
be so delegated. The <strong>using</strong> clause is defined as given above.
In this form, the statement must contain the <strong>to</strong> clause, the
<strong>using</strong> clause, or both.

<br><br>

In fact, the &quot;*&quot; can be a list of two or more tokens whose last
element is &quot;*&quot;, as in the following example:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    delegate method {tail *} to tail
</pre></td></tr></table></p>

This implicitly defines the method <b class='cmd'>tail</b> whose subcommands will
be delegated to the <strong>tail</strong> component.

<br><br>
<dt><a name="15"><b class='cmd'>delegate</b> <strong>option</strong> <i class='arg'>namespec</i> <strong>to</strong> <i class='arg'>comp</i></a><dd>

<dt><a name="16"><b class='cmd'>delegate</b> <strong>option</strong> <i class='arg'>namespec</i> <strong>to</strong> <i class='arg'>comp</i> <strong>as</strong> <i class='arg'>target</i></a><dd>


<dt><a name="17"><b class='cmd'>delegate</b> <strong>option</strong> <strong>*</strong> <strong>to</strong> <i class='arg'>comp</i></a><dd>

<dt><a name="18"><b class='cmd'>delegate</b> <strong>option</strong> <strong>*</strong> <strong>to</strong> <i class='arg'>comp</i> <strong>except</strong> <i class='arg'>exceptions</i></a><dd>


Defines a delegated option; the <i class='arg'>namespec</i> is defined as for the
<b class='cmd'>option</b> statement.

When the <strong>configure</strong>, <strong>configurelist</strong>, or <strong>cget</strong>
instance method is used to set or retrieve the option's value, the
equivalent <strong>configure</strong> or <strong>cget</strong> command will be applied
to the component as though these <b class='cmd'>onconfigure</b> and <b class='cmd'>oncget</b>
handlers were defined, where <i class='arg'>name</i> is the option name from the
<i class='arg'>namespec</i>:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    onconfigure name {value} {
        $comp configure name $value
    }

    oncget name {
        return [$comp cget name]
    }
</pre></td></tr></table></p>

If the <strong>as</strong> clause is specified, then the <i class='arg'>target</i> option
name is used in place of <i class='arg'>name</i>.

<br><br>

The form <b class='cmd'>delegate option *</b> delegates all unknown method names to the
specified <i class='arg'>comp</i>onent.  The <strong>except</strong> clause can be used to
specify a list of <i class='arg'>exceptions</i>, i.e., option names that will not
be so delegated.

<br><br>

Warning: options can only be delegated to a component if it supports
the <strong>configure</strong> and <strong>cget</strong> instance methods.

<br><br>

Note that an option cannot be both locally defined and delegated.

<br><br>
<dt><a name="19"><b class='cmd'>component</b> <i class='arg'>comp</i> ?<strong>-public</strong> <i class='arg'>method</i>? ?<strong>-inherit</strong> <i class='arg'>flag</i>?</a><dd>


Explicitly declares a component called <i class='arg'>comp</i>, and automatically
defines the component's instance variable.  

<br><br>

If the <strong>-public</strong> option is specified, then the option is made
public by defining a <i class='arg'>method</i> whose subcommands are delegated
to the component e.g., specifying <strong>-public mycomp</strong> is
equivalent to the following:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    component mycomp
    delegate method {mymethod *} to mycomp
</pre></td></tr></table></p>

If the <strong>-inherit</strong> option is specified, then <i class='arg'>flag</i> must be a
Boolean value; if <i class='arg'>flag</i> is true then all unknown methods and
options will be delegated to this component.  The name <strong>-inherit</strong>
implies that instances of this new type inherit, in a sense, the
methods and options of the component. That is, <strong>-inherit yes</strong> is
equivalent to:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    component mycomp
    delegate option * to mycomp
    delegate method * to mycomp
</pre></td></tr></table></p>

<br><br>
<dt><a name="20"><b class='cmd'>delegate</b> <strong>typemethod</strong> <i class='arg'>name</i> <strong>to</strong> <i class='arg'>comp</i> ?<strong>as</strong> <i class='arg'>target</i>?</a><dd>


Delegates type method <i class='arg'>name</i> to type component <i class='arg'>comp</i>.  That is, when
type method <i class='arg'>name</i> is called on this type, the type method
and its arguments will be passed to the named type component's command
instead.  That is, the following statement

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    delegate typemethod lostdogs to pound
</pre></td></tr></table></p>

is roughly equivalent to this explicitly defined method:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    typemethod lostdogs {args} {
        uplevel $pound lostdogs $args
    }
</pre></td></tr></table></p>

As with type methods, the <i class='arg'>name</i> may have multiple tokens; in this
case, the last token of the name is assumed to be the name of the
component's method.

<br><br>

The optional <strong>as</strong> clause allows you to specify the delegated
method name and possibly add some arguments:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    delegate typemethod lostdogs to pound as &quot;get lostdogs&quot;
</pre></td></tr></table></p>

<br><br>

A type method cannot be both locally defined and delegated.

<br><br>
<dt><a name="21"><b class='cmd'>delegate</b> <strong>typemethod</strong> <i class='arg'>name</i> ?<strong>to</strong> <i class='arg'>comp</i>? <strong>using</strong> <i class='arg'>pattern</i></a><dd>


In this form of the <b class='cmd'>delegate</b> statement, the <strong>using</strong> clause
is used to specify the precise form of the command to which type method 
<i class='arg'>name</i> name is delegated.  In this form, the <strong>to</strong> clause is
optional, since the chosen command might not involve any particular
type component.

<br><br>

The value of the <strong>using</strong> clause is a list that may contain 
any or all of the following substitution codes; these codes are
substituted with the described value to build the delegated command
prefix.  Note that the following two statements are equivalent:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    delegate typemethod lostdogs to pound
    delegate typemethod lostdogs to pound using &quot;%c %m&quot;
</pre></td></tr></table></p>

Each element of the list becomes a single element of the delegated
command--it is never reparsed as a string.

<br><br>

Substitutions:
<br><br>
<dl>
<dt><strong>%%</strong><dd>

This is replaced with a single &quot;%&quot;.  Thus, to pass the string &quot;%c&quot;
to the command as an argument, you'd write &quot;%%c&quot;.

<br><br>
<dt><strong>%c</strong><dd>

This is replaced with the named type component's command.

<br><br>
<dt><strong>%m</strong><dd>

This is replaced with the final token of the type method <i class='arg'>name</i>; if
the type method <i class='arg'>name</i> has one token, this is identical to <strong>%M</strong>.

<br><br>
<dt><strong>%M</strong><dd>

This is replaced by the type method <i class='arg'>name</i>; if the <i class='arg'>name</i> consists
of multiple tokens, they are joined by space characters.

<br><br>
<dt><strong>%j</strong><dd>

This is replaced by the type method <i class='arg'>name</i>; if the <i class='arg'>name</i> consists
of multiple tokens, they are joined by underscores (&quot;_&quot;).

<br><br>
<dt><strong>%t</strong><dd>

This is replaced with the fully qualified type name.

</dl>

<dt><a name="22"><b class='cmd'>delegate</b> <strong>typemethod</strong> <strong>*</strong> ?<strong>to</strong> <i class='arg'>comp</i>? ?<strong>using</strong> <i class='arg'>pattern</i>? ?<strong>except</strong> <i class='arg'>exceptions</i>?</a><dd>


The form <b class='cmd'>delegate typemethod *</b> delegates all unknown type
method names to the
specified type component.  The <strong>except</strong> clause can be used to
specify a list of <i class='arg'>exceptions</i>, i.e., type method names that will not
be so delegated. The <strong>using</strong> clause is defined as given above.
In this form, the statement must contain the <strong>to</strong> clause, the
<strong>using</strong> clause, or both.

<br><br>

<strong>Note:</strong> By default, Snit interprets <b class='cmd'>$type foo</b>, where
<strong>foo</strong> is
not a defined type method, as equivalent to <b class='cmd'>$type create foo</b>, where
<strong>foo</strong> is the name of a new instance of the type.  If you 
use <strong>delegate typemethod *</strong>, then the <strong>create</strong> type
method must always be used explicitly.

<br><br>

The &quot;*&quot; can be a list of two or more tokens whose last
element is &quot;*&quot;, as in the following example:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    delegate typemethod {tail *} to tail
</pre></td></tr></table></p>

This implicitly defines the type method <b class='cmd'>tail</b> whose subcommands will
be delegated to the <strong>tail</strong> type component.

<br><br>
<dt><a name="23"><b class='cmd'>typecomponent</b> <i class='arg'>comp</i> ?<strong>-public</strong> <i class='arg'>typemethod</i>? ?<strong>-inherit</strong> <i class='arg'>flag</i>?</a><dd>


Explicitly declares a type component called <i class='arg'>comp</i>, and automatically
defines the component's type variable.  A type component is an arbitrary
command to which type methods and instance methods can be delegated;
the command's name is stored in a type variable.

<br><br>

If the <strong>-public</strong> option is specified, then the type component is made
public by defining a <i class='arg'>typemethod</i> whose subcommands are delegated to
the type component, e.g., specifying <strong>-public mytypemethod</strong> 
is equivalent to the following:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    typecomponent mycomp
    delegate typemethod {mytypemethod *} to mycomp
</pre></td></tr></table></p>

If the <strong>-inherit</strong> option is specified, then <i class='arg'>flag</i> must be a
Boolean value; if <i class='arg'>flag</i> is true then all unknown type methods
will be delegated to this type component. (See the note on &quot;delegate
typemethod *&quot;, above.) The name <strong>-inherit</strong>
implies that this type inherits, in a sense, the behavior of
the type component. That is, <strong>-inherit yes</strong> is equivalent to:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    typecomponent mycomp
    delegate typemethod * to mycomp
</pre></td></tr></table></p>

<br><br>
<dt><a name="24"><b class='cmd'>pragma</b> ?<i class='arg'>options...</i>?</a><dd>


The <b class='cmd'>pragma</b> statement provides control over how Snit generates a
type.  It takes the following options; in each case, <i class='arg'>flag</i> must
be a Boolean value recognized by Tcl, e.g., <strong>0</strong>, <strong>1</strong>, 
<strong>yes</strong>, <strong>no</strong>, and so
on.

<br><br>

By setting the <strong>-hastypeinfo</strong>, <strong>-hastypedestroy</strong>, and
<strong>-hasinstances</strong> pragmas to false and defining appropriate
type methods, you can create an ensemble command without any extraneous
behavior.

<br><br>
<dl>
<dt><strong>-canreplace</strong> <i class='arg'>flag</i><dd>

If false (the default) Snit will not create an instance of a
<b class='cmd'>snit::type</b> that has the same name as an existing command; this
prevents subtle errors.  Setting this pragma to true restores the
behavior of Snit V0.93 and earlier versions.

<br><br>
<dt><strong>-hastypeinfo</strong> <i class='arg'>flag</i><dd>

If true (the default), the generated type will have a type method
called <b class='cmd'>info</b> that is used for type introspection; the <b class='cmd'>info</b>
type method is documented below.  If false, it will not.

<br><br>
<dt><strong>-hastypedestroy</strong> <i class='arg'>flag</i><dd>

If true (the default), the generated type will have a type method
called <b class='cmd'>destroy</b> that is used to destroy the type and all of its
instances.  The <b class='cmd'>destroy</b> type method is documented below.  If
false, it will not.

<br><br>
<dt><strong>-hastypemethods</strong> <i class='arg'>flag</i><dd>

If true (the default), the generated type's type command will have 
subcommands (type methods) as usual.  If false, the type command
will serve only to create instances of the type; the first argument
is the instance name.

<br><br>

This pragma and <strong>-hasinstances</strong> cannot both be set false.

<br><br>
<dt><strong>-hasinstances</strong> <i class='arg'>flag</i><dd>

If true (the default), the generated type will have a type method 
called <b class='cmd'>create</b> that is used to create instances of the type,
along with a variety of instance-related features.  If false, it will
not. 

<br><br>

This pragma and <strong>-hastypemethods</strong> cannot both be set false.

<br><br>
<dt><strong>-hasinfo</strong> <i class='arg'>flag</i><dd>

If true (the default), instances of the generated type will have 
an instance method called <strong>info</strong> that is used for 
instance introspection; the <strong>info</strong>
method is documented below.  If false, it will not.

<br><br>
<dt><strong>-simpledispatch</strong> <i class='arg'>flag</i><dd>

This pragma is intended to make simple, heavily-used abstract
data types (e.g., stacks and queues) more efficient.

<br><br>

If false (the default), instance methods are dispatched normally.  If
true, a faster dispatching scheme is used instead.
The speed comes at a price; with <strong>-simpledispatch yes</strong> you 
get the following limitations:

<br><br>
<ul>

<li> Methods cannot be delegated.
<br><br>
<li> <b class='cmd'>uplevel</b> and <b class='cmd'>upvar</b> do not work as expected: the
caller's scope is two levels up rather than one.
<br><br>
<li> The option-handling methods 
(<b class='cmd'>cget</b>, <b class='cmd'>configure</b>, and <b class='cmd'>configurelist</b>) are very
slightly slower.
</ul>

</dl>

<dt><a name="25"><b class='cmd'>expose</b> <i class='arg'>comp</i></a><dd>

<dt><a name="26"><b class='cmd'>expose</b> <i class='arg'>comp</i> <strong>as</strong> <i class='arg'>method</i></a><dd>


<! --    --     The word &quot;Deprecated&quot; really needs to be boldface, and   --     there's no good way to do it, so I'm using &quot;const&quot;.   -- 
   -->

<strong>Deprecated.</strong>  To expose component <i class='arg'>comp</i> publicly, use
<b class='cmd'>component</b>'s <strong>-public</strong> option.

<br><br>
<dt><a name="27"><b class='cmd'>onconfigure</b> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a><dd>


<strong>Deprecated.</strong>  Define <b class='cmd'>option</b>'s <strong>-configuremethod</strong> 
option instead.

<br><br>

As of version 0.95, the following definitions,

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option -myoption
    onconfigure -myoption {value} {
        # Code to save the option's value
    }
</pre></td></tr></table></p>

are implemented as follows:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option -myoption -configuremethod _configure-myoption
    method _configure-myoption {_option value} {
        # Code to save the option's value
    }
</pre></td></tr></table></p>

<br><br>
<dt><a name="28"><b class='cmd'>oncget</b> <i class='arg'>name</i> <i class='arg'>body</i></a><dd>


<strong>Deprecated.</strong>  Define <b class='cmd'>option</b>'s <strong>-cgetmethod</strong> 
option instead.

<br><br>

As of version 0.95, the following definitions,

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option -myoption
    oncget -myoption {
        # Code to return the option's value
    }
</pre></td></tr></table></p>

are implemented as follows:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option -myoption -cgetmethod _cget-myoption
    method _cget-myoption {_option} {
        # Code to return the option's value
    }
</pre></td></tr></table></p>

</dl>


<dt><a name="29"><b class='cmd'>snit::widget</b> <i class='arg'>name</i> <i class='arg'>definition</i></a><dd>


This command defines a Snit megawidget type with the specified
<i class='arg'>name</i>.  The <i class='arg'>definition</i> is defined as for <b class='cmd'>snit::type</b>.
 A <b class='cmd'>snit::widget</b> differs from a <b class='cmd'>snit::type</b>
in these ways:

<br><br>
<ul>
<li>

Every instance of a <b class='cmd'>snit::widget</b> has an automatically-created
component called <strong>hull</strong>, which is normally a Tk frame widget.
Other widgets created as part of the megawidget will be created within
this widget.

<br><br>

The hull component is initially created with the requested widget
name; then Snit does some magic, renaming the hull component and
installing its own instance command in its place.

The hull component's new name is saved in an instance variable called
<strong>hull</strong>.

<br><br>
<li>

The name of an instance must be valid Tk window name, and the parent
window must exist.

</ul>

A <b class='cmd'>snit::widget</b> definition can include any of statements allowed
in a <b class='cmd'>snit::type</b> definition, and may also include the following:

<br><br>
<dl>

<dt><a name="30"><b class='cmd'>widgetclass</b> <i class='arg'>name</i></a><dd>


Sets the <b class='cmd'>snit::widget</b>'s widget class to <i class='arg'>name</i>, overriding
the default.  See <a href="#the_tk_option_database">The Tk Option Database</a> for more
information.

<br><br>
<dt><a name="31"><b class='cmd'>hulltype</b> <i class='arg'>type</i></a><dd>


Determines the kind of widget used as the <b class='cmd'>snit::widget</b>'s hull.
The <i class='arg'>type</i> may be <strong>frame</strong> (the default) or <strong>toplevel</strong>.

</dl>
       
<dt><a name="32"><b class='cmd'>snit::widgetadaptor</b> <i class='arg'>name</i> <i class='arg'>definition</i></a><dd>


This command defines a Snit megawidget type with the specified name.
It differs from <b class='cmd'>snit::widget</b> in that the instance's <strong>hull</strong>
component is not created automatically, but is created in the
constructor and installed using the <b class='cmd'>installhull</b> command.  Once
the hull is installed, its instance command is renamed and replaced as
with normal <b class='cmd'>snit::widget</b>s.  The original command is again
accessible in the instance variable <strong>hull</strong>.

<br><br>

Note that in general it is not possible to change the
<em>widget class</em> of a <b class='cmd'>snit::widgetadaptor</b>'s hull widget.

<br><br>

See <a href="#the_tk_option_database">The Tk Option Database</a> for information on how
<b class='cmd'>snit::widgetadaptor</b>s interact with the option database.

<br><br>
<dt><a name="33"><b class='cmd'>snit::typemethod</b> <i class='arg'>type</i> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a><dd>


Defines a new type method (or redefines an existing type method)
for a previously existing <i class='arg'>type</i>.

<br><br>
<dt><a name="34"><b class='cmd'>snit::method</b> <i class='arg'>type</i> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a><dd>


Defines a new instance method (or redefines an existing instance
method) for a previously existing <i class='arg'>type</i>.  Note that delegated
instance methods can't be redefined.

<br><br>
<dt><a name="35"><b class='cmd'>snit::macro</b> <i class='arg'>name</i> <i class='arg'>arglist</i> <i class='arg'>body</i></a><dd>


Defines a Snit macro with the specified <i class='arg'>name</i>, <i class='arg'>arglist</i>, and
<i class='arg'>body</i>.  Macros are used to define new type and widget
definition statements in terms of the statements defined in this man
page.

<br><br>

A macro is simply a Tcl proc that is defined in the slave interpreter
used to compile type and widget definitions.  Thus, macros have 
access to all of the type and widget definition statements.  See 
<a href="#macros_and_meta-programming">Macros and Meta-programming</a> for more details.

<br><br>

The macro <i class='arg'>name</i> cannot be the same as any standard Tcl command, 
or any Snit type or widget definition statement, e.g., you can't
redefine the <b class='cmd'>method</b> or <b class='cmd'>delegate</b> statements, or the 
standard <b class='cmd'>set</b>, <b class='cmd'>list</b>, or <b class='cmd'>string</b> commands.

<br><br>
<dt><a name="36"><b class='cmd'>snit::compile</b> <i class='arg'>which</i> <i class='arg'>type</i> <i class='arg'>body</i></a><dd>


Snit defines a type, widget, or widgetadaptor by &quot;compiling&quot; the
definition into a Tcl script; this script is then evaluated in the
Tcl interpreter, which actually defines the new type.

<br><br>

This command exposes the &quot;compiler&quot;.  Given a definition <i class='arg'>body</i>
for the named <i class='arg'>type</i>, where <i class='arg'>which</i> is <strong>type</strong>, 
<strong>widget</strong>, or <strong>widgetadaptor</strong>, <b class='cmd'>snit::compile</b> returns a list
of two elements.  The first element is the fully qualified type name;
the second element is the definition script.

<br><br>

<b class='cmd'>snit::compile</b> is useful when additional processing
must be done on the Snit-generated code--if it must be instrumented,
for example, or run through the TclDevKit compiler.  In addition, the
returned script could be saved in a &quot;.tcl&quot; file and used to define the
type as part of an application or library, thus saving the compilation
overhead at application start-up.  Note that the
same version of Snit must be used at run-time as at compile-time.

</dl>

<h3><a name="the_type_command">The Type Command</a></h3>
<p>

A type or widget definition creates a type command, which is used to
create instances of the type.  The type command has this form:

<p>
<dl>
<dt><a name="37"><b class='cmd'>$type</b> <i class='arg'>typemethod</i> <i class='arg'>args</i>...</a><dd>


The <i class='arg'>typemethod</i> can be any of the 
<a href="#standard_type_methods">Standard Type Methods</a> (e.g., <strong>create</strong>), 
or any type method defined in the type
definition.

The subsequent <i class='arg'>args</i> depend on the specific <i class='arg'>typemethod</i>
chosen.

<br><br>

The type command is most often used to create new instances of the 
type; hence, the <strong>create</strong> method is assumed if the first
argument to the type command doesn't name a valid type method, unless
the type definition includes <b class='cmd'>delegate typemethod *</b> or the 
<strong>-hasinstances</strong> pragma is set to false.

<br><br>

Furthermore, Snit type commands can be called with no arguments at
all; in this case, the type command creates an instance with an
automatically generated name.  In other words, provided that the type
has instances, the following commands are equivalent:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>snit::type dog { ... }

set mydog [dog create %AUTO%]
set mydog [dog %AUTO%]
set mydog [dog]
</pre></td></tr></table></p>

This doesn't work for Snit widgets, for obvious reasons.

</dl>

<h3><a name="standard_type_methods">Standard Type Methods</a></h3>
<p>

In addition to any type methods in the type's definition, all type and
widget commands will usually have at least the following subcommands:

<p>

<dl>

<dt><a name="38"><b class='cmd'>$type</b> <strong>create</strong> <i class='arg'>name</i> ?<i class='arg'>option</i> <i class='arg'>value</i> ...?</a><dd>


Creates a new instance of the type, giving it the specified <i class='arg'>name</i>
and calling the type's constructor.

<br><br>

For <b class='cmd'>snit::type</b>s, if <i class='arg'>name</i> is not a fully-qualified command
name, it is assumed to be a name in the namespace in which the call to
<b class='cmd'>snit::type</b> appears.  The method returns the fully-qualified
instance name.

<br><br>

For <b class='cmd'>snit::widget</b>s and <b class='cmd'>snit::widgetadaptor</b>s, <i class='arg'>name</i>
must be a valid widget name; the method returns the widget name.

<br><br>

So long as <i class='arg'>name</i> does not conflict with any defined type method
name the <strong>create</strong> keyword may be omitted, unless
the type definition includes <b class='cmd'>delegate typemethod *</b> or the 
<strong>-hasinstances</strong> pragma is set to false.

<br><br>

If the <i class='arg'>name</i> includes the string <strong>%AUTO%</strong>, it will be
replaced with the string <strong>$type$counter</strong> where <strong>$type</strong> is
the type name and <strong>$counter</strong> is a counter that increments each
time <strong>%AUTO%</strong> is used for this type.

<br><br>

By default, any arguments following the <i class='arg'>name</i> will be a list of
<i class='arg'>option</i> names and their <i class='arg'>value</i>s; however, a type's
constructor can specify a different argument list.

<br><br>

As of Snit V0.95, <strong>create</strong> will throw an error if the <i class='arg'>name</i>
is the same as any existing command--note that this was always true
for <b class='cmd'>snit::widget</b>s and <b class='cmd'>snit::widgetadaptor</b>s.  You can
restore the previous behavior using the <strong>-canreplace</strong> pragma.


<br><br>
<dt><a name="39"><b class='cmd'>$type</b> <strong>info typevars</strong> ?<i class='arg'>pattern</i>?</a><dd>


Returns a list of the type's type variables (excluding Snit internal
variables); all variable names are fully-qualified.

<br><br>

If <i class='arg'>pattern</i> is given, it's used as a <b class='cmd'>string match</b>
pattern; only names that match the pattern are returned.


<br><br>
<dt><a name="40"><b class='cmd'>$type</b> <strong>info typemethods</strong> ?<i class='arg'>pattern</i>?</a><dd>


Returns a list of the names of the type's type methods.  If the type
definition includes <b class='cmd'>delegate typemethod *</b>, the list will
include only the names of those implicitly delegated type methods 
that have been called at least once and are still in the type method cache.

<br><br>

If <i class='arg'>pattern</i> is given, it's used as a <b class='cmd'>string match</b>
pattern; only names that match the pattern are returned.


<br><br>
<dt><a name="41"><b class='cmd'>$type</b> <strong>info instances</strong> ?<i class='arg'>pattern</i>?</a><dd>


Returns a list of the type's instances.  For <b class='cmd'>snit::type</b>s, it
will be a list of fully-qualified instance names;
for <b class='cmd'>snit::widget</b>s, it will be a list of Tk widget names.

<br><br>

If <i class='arg'>pattern</i> is given, it's used as a <b class='cmd'>string match</b>
pattern; only names that match the pattern are returned.


<br><br>
<dt><a name="42"><b class='cmd'>$type</b> <strong>destroy</strong></a><dd>


Destroys the type's instances, the type's namespace, and the type
command itself.

</dl>

<h3><a name="the_instance_command">The Instance Command</a></h3>
<p>

A Snit type or widget's <strong>create</strong> type method creates objects of
the type; each object has a unique name that is also a Tcl command.
This command is used to access the object's methods and data, and has
this form:

<p>

<dl>
<dt><a name="43"><b class='cmd'>$object</b> <i class='arg'>method</i> <i class='arg'>args...</i></a><dd>


The <i class='arg'>method</i> can be any of the 
<a href="#standard_instance_methods">Standard Instance Methods</a>, or any instance method 
defined in the type definition.

The subsequent <i class='arg'>args</i> depend on the specific <i class='arg'>method</i> chosen.

</dl>

<h3><a name="standard_instance_methods">Standard Instance Methods</a></h3>
<p>

In addition to any delegated or locally-defined instance methods in
the type's definition, all Snit objects will have at least the
following subcommands:

<p>

<dl>
<dt><a name="44"><b class='cmd'>$object</b> <strong>configure</strong> ?<i class='arg'>option</i>? ?<i class='arg'>value</i>? ...</a><dd>


Assigns new values to one or more options.  If called with one
argument, an <i class='arg'>option</i> name, returns a list describing the option,
as Tk widgets do; if called with no arguments, returns a list of lists
describing all options, as Tk widgets do.

<br><br>

Warning: This information will be available for delegated options only
if the component to which they are delegated has a <strong>configure</strong>
method that returns this same kind of information.

<br><br>

Note: Snit defines this method only if the type has at least one
option.

<br><br>
<dt><a name="45"><b class='cmd'>$object</b> <strong>configurelist</strong> <i class='arg'>optionlist</i></a><dd>


Like <strong>configure</strong>, but takes one argument, a list of options and
their values.  It's mostly useful in the type constructor, but can be
used anywhere.

<br><br>

Note: Snit defines this method only if the type has at least one
option.

<br><br>
<dt><a name="46"><b class='cmd'>$object</b> <strong>cget</strong> <i class='arg'>option</i></a><dd>


Returns the option's value.

<br><br>

Note: Snit defines this method only if the type has at least one
option.

<br><br>
<dt><a name="47"><b class='cmd'>$object</b> <strong>destroy</strong></a><dd>


Destroys the object, calling the <b class='cmd'>destructor</b> and freeing all
related memory.

<br><br>

<em>Note:</em>

The <strong>destroy</strong> method isn't defined for <b class='cmd'>snit::widget</b> or
<b class='cmd'>snit::widgetadaptor</b> objects; instances of these are destroyed by
calling <strong>Tk</strong>'s <b class='cmd'>destroy</b> command, just as normal
widgets are.


<br><br>
<dt><a name="48"><b class='cmd'>$object</b> <strong>info type</strong></a><dd>


Returns the instance's type.


<br><br>
<dt><a name="49"><b class='cmd'>$object</b> <strong>info vars</strong> ?<i class='arg'>pattern</i>?</a><dd>


Returns a list of the object's instance variables (excluding Snit
internal variables).  The names are fully qualified.

<br><br>

If <i class='arg'>pattern</i> is given, it's used as a <b class='cmd'>string match</b>
pattern; only names that match the pattern are returned.


<br><br>
<dt><a name="50"><b class='cmd'>$object</b> <strong>info typevars</strong> ?<i class='arg'>pattern</i>?</a><dd>


Returns a list of the object's type's type variables (excluding Snit
internal variables).  The names are fully qualified.

<br><br>

If <i class='arg'>pattern</i> is given, it's used as a <b class='cmd'>string match</b>
pattern; only names that match the pattern are returned.


<br><br>
<dt><a name="51"><b class='cmd'>$object</b> <strong>info typemethods</strong> ?<i class='arg'>pattern</i>?</a><dd>


Returns a list of the names of the instance's type's type methods.  If the type
definition includes <b class='cmd'>delegate typemethod *</b>, the list will
include only the names of those implicitly delegated type methods 
that have been called at least once and are still in the type method cache.

<br><br>

If <i class='arg'>pattern</i> is given, it's used as a <b class='cmd'>string match</b>
pattern; only names that match the pattern are returned.


<br><br>
<dt><a name="52"><b class='cmd'>$object</b> <strong>info options</strong> ?<i class='arg'>pattern</i>?</a><dd>


Returns a list of the object's option names.  This always includes
local options and explicitly delegated options.  If unknown options
are delegated as well, and if the component to which they are
delegated responds to <b class='cmd'>$object configure</b> like Tk widgets do,
then the result will include all possible unknown options that can
be delegated to the component.

<br><br>

If <i class='arg'>pattern</i> is given, it's used as a <b class='cmd'>string match</b>
pattern; only names that match the pattern are returned.

<br><br>

Note that the return value might be different for different instances
of the same type, if component object types can vary from one instance
to another.

<br><br>
<dt><a name="53"><b class='cmd'>$object</b> <strong>info methods</strong> ?<i class='arg'>pattern</i>?</a><dd>


Returns a list of the names of the instance's methods.  If the type
definition includes <b class='cmd'>delegate method *</b>, the list will
include only the names of those implicitly delegated methods that have
been called at least once and are still in the method cache.

<br><br>

If <i class='arg'>pattern</i> is given, it's used as a <b class='cmd'>string match</b>
pattern; only names that match the pattern are returned.


</dl>

<h3><a name="commands_for_use_in_object_code">Commands for use in Object Code</a></h3>
<p>

Snit defines the following commands for use in your object code:
that is, for use in type methods, instance methods, constructors,
destructors, onconfigure handlers, oncget handlers, and procs.
They do not reside in the ::snit:: namespace; instead, they are
created with the type, and can be used without qualification.


<dl>

<dt><a name="54"><b class='cmd'>mymethod</b> <i class='arg'>name</i> ?<i class='arg'>args...</i>?</a><dd>


The <b class='cmd'>mymethod</b> command is used for formatting callback commands to
be passed to other objects.  It returns a command that when called
will invoke method <i class='arg'>name</i> with the specified arguments, plus of
course any arguments added by the caller.  In other words, both of the
following commands will cause the object's 
<strong>dosomething</strong> method to be called when the <b class='cmd'>$button</b> is pressed:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    $button configure -command [list $self dosomething myargument]
       
    $button configure -command [mymethod dosomething myargument]
</pre></td></tr></table></p>

The chief distinction between the two is that the latter form will not
break if the object's command is renamed.

<br><br>
<dt><a name="55"><b class='cmd'>mytypemethod</b> <i class='arg'>name</i> ?<i class='arg'>args...</i>?</a><dd>


The <b class='cmd'>mytypemethod</b> command is used for formatting callback commands to
be passed to other objects.  It returns a command that when called
will invoke type method <i class='arg'>name</i> with the specified arguments, plus of
course any arguments added by the caller.  In other words, both of the
following commands will cause the object's <strong>dosomething</strong> type method
to be called when <b class='cmd'>$button</b> is pressed:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    $button configure -command [list $type dosomething myargument]
       
    $button configure -command [mytypemethod dosomething myargument]
</pre></td></tr></table></p>

Type commands cannot be renamed, so in practice there's little
difference between the two forms.  <b class='cmd'>mytypemethod</b> is provided for
parallelism with <b class='cmd'>mymethod</b>.

<br><br>
<dt><a name="56"><b class='cmd'>myproc</b> <i class='arg'>name</i> ?<i class='arg'>args...</i>?</a><dd>


The <b class='cmd'>myproc</b> command is used for formatting callback commands to
be passed to other objects.  It returns a command that when called
will invoke the type proc <i class='arg'>name</i> with the specified arguments, plus of
course any arguments added by the caller.  In other words, both of the
following commands will cause the object's <strong>dosomething</strong> proc
to be called when <b class='cmd'>$button</b> is pressed:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    $button configure -command [list ${type}::dosomething myargument]
       
    $button configure -command [myproc dosomething myargument]
</pre></td></tr></table></p>

<br><br>
<dt><a name="57"><b class='cmd'>myvar</b> <i class='arg'>name</i></a><dd>


Given an instance variable name, returns the fully qualified name.
Use this if you're passing the variable to some other object, e.g., as
a <strong>-textvariable</strong> to a Tk label widget.


<br><br>
<dt><a name="58"><b class='cmd'>mytypevar</b> <i class='arg'>name</i></a><dd>


Given an type variable name, returns the fully qualified name.  Use
this if you're passing the variable to some other object, e.g., as a
<strong>-textvariable</strong> to a Tk label widget.

<br><br>
<dt><a name="59"><b class='cmd'>from</b> <i class='arg'>argvName</i> <i class='arg'>option</i> ?<i class='arg'>defvalue</i>?</a><dd>


The <b class='cmd'>from</b> command plucks an option value from a list of options
and their values, such as is passed into a type's <b class='cmd'>constructor</b>.
<i class='arg'>argvName</i> must be the name of a variable containing such a list;
<i class='arg'>option</i> is the name of the specific option.

<br><br>

<b class='cmd'>from</b> looks for <i class='arg'>option</i> in the option list.  If it is found,
it and its value are removed from the list, and the value is returned.
If <i class='arg'>option</i> doesn't appear in the list, then the <i class='arg'>defvalue</i> is
returned.

If the option is locally-defined option, and <i class='arg'>defvalue</i> is
not specified, then the option's default value as specified in the
type definition will be returned instead.

<br><br>
<dt><a name="60"><b class='cmd'>install</b> <i class='arg'>compName</i> <strong>using</strong> <i class='arg'>objType</i> <i class='arg'>objName</i> <i class='arg'>args...</i></a><dd>


Creates a new object of type <i class='arg'>objType</i> called <i class='arg'>objName</i>
and installs it as component <i class='arg'>compName</i>, 
as described in <a href="#components_and_delegation">Components and Delegation</a>.  Any additional
<i class='arg'>args...</i> are passed along with the name to the <i class='arg'>objType</i>
command.

If this is a <b class='cmd'>snit::type</b>, then the following two commands are
equivalent:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    install myComp using myObjType $self.myComp args...

    set myComp [myObjType $self.myComp args...]
</pre></td></tr></table></p>

Note that whichever method is used, <i class='arg'>compName</i> must still be
declared in the type definition using <b class='cmd'>component</b>, or must be
referenced in at least one <b class='cmd'>delegate</b> statement.

<br><br>

If this is a <b class='cmd'>snit::widget</b> or <b class='cmd'>snit::widgetadaptor</b>, and if
options have been delegated to component <i class='arg'>compName</i>, then those
options will receive default values from the Tk option database.  Note
that it doesn't matter whether the component to be installed is a
widget or not.  See <a href="#the_tk_option_database">The Tk Option Database</a> for more
information.

<br><br>

<b class='cmd'>install</b> cannot be used to install type components; just assign
the type component's command name to the type component's variable
instead.

<br><br>
<dt><a name="61"><b class='cmd'>installhull</b> <strong>using</strong> <i class='arg'>widgetType</i> <i class='arg'>args...</i></a><dd>

<dt><a name="62"><b class='cmd'>installhull</b> <i class='arg'>name</i></a><dd>


The constructor of a <b class='cmd'>snit::widgetadaptor</b> must create a widget to
be the object's hull component; the widget is installed as the hull
component using this command.  Note that the installed widget's name
must be <strong>$win</strong>.

This command has two forms.

<br><br>

The first form specifies the <i class='arg'>widgetType</i> and the <i class='arg'>args...</i>
(that is, the hardcoded option list) to use in creating the hull.
Given this form, <b class='cmd'>installhull</b> creates the hull widget, and
initializes any options delegated to the hull from the Tk option
database.

<br><br>

In the second form, the hull widget has already been created; note
that its name must be &quot;$win&quot;.  In this case, the Tk option database is
<em>not</em> queried for any options delegated to the hull.

The longer form is preferred; however, the shorter form allows the
programmer to adapt a widget created elsewhere, which is sometimes
useful.  For example, it can be used to adapt a &quot;page&quot; widget created
by a <strong>BWidgets</strong> tabbed notebook or pages manager widget.

<br><br>

See <a href="#the_tk_option_database">The Tk Option Database</a> for more information
about <b class='cmd'>snit::widgetadaptor</b>s and the option database.

<br><br>
<dt><a name="63"><b class='cmd'>variable</b> <i class='arg'>name</i></a><dd>


Normally, instance variables are defined in the type definition along
with the options, methods, and so forth; such instance variables are
automatically visible in all instance code (e.g., method bodies).  However,
instance code can use the <b class='cmd'>variable</b> command to declare instance variables
that don't appear in the type definition, and also to bring variables
from other namespaces into scope in the usual way.

<br><br>

It's generally clearest to define all instance variables in the type
definition, and omit declaring them in methods and so forth.

<br><br>

Note that this is an instance-specific version of the standard Tcl 
<b class='cmd'>::variable</b> command.

<br><br>
<dt><a name="64"><b class='cmd'>typevariable</b> <i class='arg'>name</i></a><dd>


Normally, type variables are defined in the type definition, along
with the instance variables; such type variables are automatically
visible in all of the type's code.  However, type methods, instance
methods and so forth can use <b class='cmd'>typevariable</b> to declare type 
variables that don't appear in the type definition.

<br><br>

It's generally clearest to declare all type variables in the type
definition, and omit declaring them in methods, type methods, etc.

<br><br>
<dt><a name="65"><b class='cmd'>varname</b> <i class='arg'>name</i></a><dd>


<strong>Deprecated.</strong>  Use <b class='cmd'>myvar</b> instead.

<br><br>

Given an instance variable name, returns the fully qualified name.
Use this if you're passing the variable to some other object, e.g., as
a <strong>-textvariable</strong> to a Tk label widget.


<br><br>
<dt><a name="66"><b class='cmd'>typevarname</b> <i class='arg'>name</i></a><dd>


<strong>Deprecated.</strong>  Use <b class='cmd'>mytypevar</b> instead.

<br><br>

Given a type variable name, returns the fully qualified name.  Use
this if you're passing the type variable to some other object, e.g., as a
<strong>-textvariable</strong> to a Tk label widget.

<br><br>
<dt><a name="67"><b class='cmd'>codename</b> <i class='arg'>name</i></a><dd>


<strong>Deprecated.</strong>  Use <b class='cmd'>myproc</b> instead.

Given the name of a proc (but not a type or instance method), returns
the fully-qualified command name, suitable for passing as a callback.

</dl>
<p>

<h3><a name="components_and_delegation">Components and Delegation</a></h3>
<p>

When an object includes other objects, as when a toolbar contains
buttons or a GUI object contains an object that references a database,
the included object is called a component.  The standard way to handle
component objects owned by a Snit object is to declare them using
<b class='cmd'>component</b>, which creates a component instance variable.  
In the following example, a <b class='cmd'>dog</b> object has a
<b class='cmd'>tail</b> object:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::type dog {
        component mytail
    
        constructor {args} {
            set mytail [tail %AUTO% -partof $self]
            $self configurelist $args
        }
    
        method wag {} {
            $mytail wag
        }
    }
    
    snit::type tail {
        option -length 5
        option -partof
        method wag {} { return &quot;Wag, wag, wag.&quot;}
    }
</pre></td></tr></table></p>
<p>

Because the <b class='cmd'>tail</b> object's name is stored in an instance
variable, it's easily accessible in any method.

<p>

The <b class='cmd'>install</b> command provides an alternate way
to create and install the component:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::type dog {
        component mytail

        constructor {args} {
            install mytail using tail %AUTO% -partof $self
            $self configurelist $args
        }

        method wag {} {
            $mytail wag
        }
    }
</pre></td></tr></table></p>
<p>

For <b class='cmd'>snit::type</b>s, the two methods are equivalent; for
<b class='cmd'>snit::widget</b>s and <b class='cmd'>snit::widgetadaptor</b>s, the <b class='cmd'>install</b>
command properly initializes the widget's options by querying
<a href="#the_tk_option_database">The Tk Option Database</a>.

<p>

In the above examples, the <b class='cmd'>dog</b> object's <strong>wag</strong> method
simply calls the <b class='cmd'>tail</b> component's <strong>wag</strong> method.  In OO
jargon, this is called delegation.  Snit provides an easier way to do
this:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::type dog {
        delegate method wag to mytail
    
        constructor {args} {
            install mytail using tail %AUTO% -partof $self
            $self configurelist $args
        }
    }
</pre></td></tr></table></p>
<p>

The <b class='cmd'>delegate</b> statement in the type definition implicitly defines
the instance variable <strong>mytail</strong> to hold the component's name
(though it's good form to use <b class='cmd'>component</b> to declare it explicitly); it
also defines the <b class='cmd'>dog</b> object's <strong>wag</strong> method, delegating it
to the <strong>mytail</strong> component.

<p>

If desired, all otherwise unknown methods can be delegated to a
specific component:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>
    snit::type dog {
	delegate method * to mytail

	constructor {args} {
	    set mytail [tail %AUTO% -partof $self]
	    $self configurelist $args
	}

	method bark { return &quot;Bark, bark, bark!&quot; }
    }
</pre></td></tr></table></p>
<p>

In this case, a <b class='cmd'>dog</b> object will handle its own <strong>bark</strong>
method; but <strong>wag</strong> will be passed along to <b class='cmd'>mytail</b>.  Any
other method, being recognized by neither <b class='cmd'>dog</b> nor <b class='cmd'>tail</b>,
will simply raise an error.

<p>

Option delegation is similar to method delegation, except for the
interactions with the Tk option database; this is described in 
<a href="#the_tk_option_database">The Tk Option Database</a>.

<h3><a name="type_components_and_delegation">Type Components and Delegation</a></h3>
<p>

The relationship between type components and instance components is
identical to that between type variables and instance variables, and
that between type methods and instance methods.  Just as an instance
component is an instance variable that holds the name of a command, so
a type component is a type variable that holds the name of a command.
In essence, a type component is a component that's shared by every
instance of the type.

<p>

Just as <b class='cmd'>delegate method</b> can be used to delegate methods to
instance components, as described in 
<a href="#components_and_delegation">Components and Delegation</a>, so <b class='cmd'>delegate typemethod</b>
can be used to delegate type methods to type components.

<p>

Note also that as of Snit 0.95 <b class='cmd'>delegate method</b> can delegate
methods to both instance components and type components.

<h3><a name="the_tk_option_database">The Tk Option Database</a></h3>
<p>

This section describes how Snit interacts with the Tk option database,
and assumes the reader has a working knowledge of the option database
and its uses.  The book <em>Practical Programming in Tcl and Tk</em>
by Welch et al has a good introduction to the option database, as does
<em>Effective Tcl/Tk Programming</em>.

<p>

Snit is implemented so that most of the time it will simply do the
right thing with respect to the option database, provided that the
widget developer does the right thing by Snit.  The body of this
section goes into great deal about what Snit requires.  The following
is a brief statement of the requirements, for reference.

<p>

<ul>
<li>

If the <b class='cmd'>snit::widget</b>'s default widget class is not what is desired, set it
explicitly using <b class='cmd'>widgetclass</b> in the widget definition.

<br><br>
<li>

When defining or delegating options, specify the resource and class
names explicitly when if the defaults aren't what you want.

<br><br>
<li>

Use <b class='cmd'>installhull using</b> to install the hull for
<b class='cmd'>snit::widgetadaptor</b>s.

<br><br>
<li>

Use <b class='cmd'>install</b> to install all other components.

</ul>
<p>

The interaction of Tk widgets with the option database is a complex
thing; the interaction of Snit with the option database is even more
so, and repays attention to detail.

<p>

<strong>Setting the widget class:</strong> Every Tk widget has a widget class.
For Tk widgets, the widget class name is the just the widget type name
with an initial capital letter, e.g., the widget class for
<b class='cmd'>button</b> widgets is &quot;Button&quot;.

<p>

Similarly, the widget class of a <b class='cmd'>snit::widget</b> defaults to the
unqualified type name with the first letter capitalized.  For example,
the widget class of

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::widget ::mylibrary::scrolledText { ... }</pre></td></tr></table></p>
<p>

is &quot;ScrolledText&quot;.  The widget class can also be set explicitly using
the <b class='cmd'>widgetclass</b> statement within the <b class='cmd'>snit::widget</b>
definition.

<p>

Note that only <b class='cmd'>frame</b> and <b class='cmd'>toplevel</b> widgets allow the user
to change the widget class name, which is why they are the only allowable
hull types for <b class='cmd'>snit::widget</b>s.

<p>

The widget class of a <b class='cmd'>snit::widgetadaptor</b> is just the widget
class of its hull widget; this cannot be changed unless the hull
widget is a <b class='cmd'>frame</b> or <b class='cmd'>toplevel</b>, in which case it will
usually make more sense to use <b class='cmd'>snit::widget</b> rather than
<b class='cmd'>snit::widgetadaptor</b>.

<p>

<strong>Setting option resource names and classes:</strong> In Tk, every
option has three names: the option name, the resource name, and the
class name.  The option name begins with a hyphen and is all lowercase;
it's used when creating widgets, and with the <b class='cmd'>configure</b> and
<b class='cmd'>cget</b> commands.

<p>

The resource and class names are used to initialize option default
values by querying the Tk option database.  The resource name is
usually just the option name minus the hyphen, but may contain
uppercase letters at word boundaries; the class name is usually just
the resource name with an initial capital, but not always.  For
example, here are the option, resource, and class names for several
<b class='cmd'>text</b> widget options:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    -background         background         Background 
    -borderwidth        borderWidth        BorderWidth 
    -insertborderwidth  insertBorderWidth  BorderWidth 
    -padx               padX               Pad 
</pre></td></tr></table></p>
<p>

As is easily seen, sometimes the resource and class names can be
inferred from the option name, but not always.

<p>

Snit options also have a resource name and a class name.  By default,
these names follow the rule given above: the resource name is the
option name without the hyphen, and the class name is the resource
name with an initial capital.  This is true for both locally-defined
options and explicitly delegated options:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::widget mywidget {
        option -background
        delegate option -borderwidth to hull
        delegate option * to text
	# ...
    }
</pre></td></tr></table></p>
<p>

In this case, the widget class name is &quot;Mywidget&quot;.  The widget has the
following options: <strong>-background</strong>, which is locally defined, and
<strong>-borderwidth</strong>, which is explicitly delegated; all other widgets are
delegated to a component called &quot;text&quot;, which is probably a Tk

<b class='cmd'>text</b> widget.  If so, <b class='cmd'>mywidget</b> has all the same options as
a <b class='cmd'>text</b> widget.  The option, resource, and class names are as
follows:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    -background  background  Background
    -borderwidth borderwidth Borderwidth
    -padx        padX        Pad
</pre></td></tr></table></p>
<p>

Note that the locally defined option, <strong>-background</strong>, happens to have
the same three names as the standard Tk <strong>-background</strong> option; and
<strong>-pad</strong>, which is delegated implicitly to the <strong>text</strong>
component, has the
same three names for <b class='cmd'>mywidget</b> as it does for the <b class='cmd'>text</b>
widget.  <strong>-borderwidth</strong>, on the other hand, has different resource and
class names than usual, because the internal word &quot;width&quot; isn't
capitalized.  For consistency, it should be; this is done as follows:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::widget mywidget {
	option -background
	delegate option {-borderwidth borderWidth} to hull
	delegate option * to text
	# ...
    }
</pre></td></tr></table></p>
<p>

The class name will default to &quot;BorderWidth&quot;, as expected.

<p>

Suppose, however, that <b class='cmd'>mywidget</b> also delegated 
<strong>-padx</strong> and
<strong>-pady</strong> to the hull.  In this case, both the resource name and the
class name must be specified explicitly:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::widget mywidget {
	option -background
	delegate option {-borderwidth borderWidth} to hull
	delegate option {-padx padX Pad} to hull
	delegate option {-pady padY Pad} to hull
	delegate option * to text
	# ...
    }
</pre></td></tr></table></p>
<p>

<strong>Querying the option database:</strong> If you set your widgetclass and
option names as described above, Snit will query the option database
when each instance is created, and will generally do the right thing
when it comes to querying the option database.  The remainder of this
section goes into the gory details.

<p>
<strong>Initializing locally defined options:</strong>

When an instance of a snit::widget is created, its locally defined
options are initialized as follows: each option's resource and class
names are used to query the Tk option database.  If the result is
non-empty, it is used as the option's default; otherwise, the default
hardcoded in the type definition is used.  In either case, the default
can be overridden by the caller.  For example,

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option add *Mywidget.texture pebbled

    snit::widget mywidget {
	option -texture smooth
	# ...
    }

    mywidget .mywidget -texture greasy
</pre></td></tr></table></p>
<p>

Here, <strong>-texture</strong> would normally default to &quot;smooth&quot;, but because of
the entry added to the option database it defaults to &quot;pebbled&quot;.
However, the caller has explicitly overridden the default, and so the
new widget will be &quot;greasy&quot;.

<p>
<strong>Initializing options delegated to the hull:</strong>

A <b class='cmd'>snit::widget</b>'s hull is a widget, and given that its class has
been set it is expected to query the option database for itself.  The
only exception concerns options that are delegated to it with a
different name.  Consider the following code:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    option add *Mywidget.borderWidth 5
    option add *Mywidget.relief sunken
    option add *Mywidget.hullbackground red
    option add *Mywidget.background green

    snit::widget mywidget {
	delegate option -borderwidth to hull
	delegate option -hullbackground to hull as -background
	delegate option * to hull
	# ...
    }

    mywidget .mywidget

    set A [.mywidget cget -relief]
    set B [.mywidget cget -hullbackground]
    set C [.mywidget cget -background]
    set D [.mywidget cget -borderwidth]
</pre></td></tr></table></p>
<p>

The question is, what are the values of variables A, B, C and D?

<p>

The value of A is &quot;sunken&quot;.  The hull is a Tk frame that has been
given the widget class &quot;Mywidget&quot;; it will automatically query the
option database and pick up this value.  Since the <strong>-relief</strong>
option is implicitly delegated to the hull, Snit takes no action.

<p>

The value of B is &quot;red&quot;.  The hull will automatically pick up the
value &quot;green&quot; for its <strong>-background</strong> option, just as it picked up the
<strong>-relief</strong> value.  However, Snit knows that 
<strong>-hullbackground</strong> is mapped to
the hull's <strong>-background</strong> option; hence, it queries the option database
for <strong>-hullbackground</strong> and gets &quot;red&quot; and updates the hull 
accordingly.

<p>

The value of C is also &quot;red&quot;, because <strong>-background</strong> is implicitly
delegated to the hull; thus, retrieving it is the same as retrieving
<strong>-hullbackground</strong>.  Note that this case is unusual; in practice,
<strong>-background</strong> would probably be explicitly delegated to some other
component.

<p>

The value of D is &quot;5&quot;, but not for the reason you think.  Note that as
it is defined above, the resource name for <strong>-borderwidth</strong>
defaults to &quot;borderwidth&quot;, whereas the option database entry is 
&quot;borderWidth&quot;.  As with <strong>-relief</strong>, the hull picks up its 
own <strong>-borderwidth</strong> option before Snit does anything.  Because the
option is delegated under its own name, Snit assumes that the correct 
thing has happened, and doesn't worry about it any further.

<p>

For <b class='cmd'>snit::widgetadaptor</b>s, the case is somewhat altered.  Widget
adaptors retain the widget class of their hull, and the hull is not
created automatically by Snit.  Instead, the <b class='cmd'>snit::widgetadaptor</b>
must call <b class='cmd'>installhull</b> in its constructor.  The normal way to do
this is as follows:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::widgetadaptor mywidget {
	# ...
	constructor {args} {
	    # ...
	    installhull using text -foreground white
	    #
	}
	#...
    }
</pre></td></tr></table></p>
<p>

In this case, the <b class='cmd'>installhull</b> command will create the hull using
a command like this:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    set hull [text $win -foreground white]
</pre></td></tr></table></p>
<p>

The hull is a <b class='cmd'>text</b> widget, so its widget class is &quot;Text&quot;.  Just
as with <b class='cmd'>snit::widget</b> hulls, Snit assumes that it will pick up
all of its normal option values automatically; options delegated from
a different name are initialized from the option database in the same
way.

<p>
<strong>Initializing options delegated to other components:</strong>

Non-hull components are matched against the option database in two
ways.  First, a component widget remains a widget still, and therefore
is initialized from the option database in the usual way.

Second, the option database is queried for all options delegated to
the component, and the component is initialized accordingly--provided
that the <b class='cmd'>install</b> command is used to create it.

<p>

Before option database support was added to Snit, the usual way to
create a component was to simply create it in the constructor and
assign its command name to the component variable:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::widget mywidget {
	delegate option -background to myComp

	constructor {args} {
	    set myComp [text $win.text -foreground black]
	}
    }
</pre></td></tr></table></p>
<p>

The drawback of this method is that Snit has no opportunity to
initialize the component properly.  Hence, the following approach is
now used:

<p>
<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::widget mywidget {
	delegate option -background to myComp

	constructor {args} {
	    install myComp using text $win.text -foreground black
	}
    }
</pre></td></tr></table></p>
<p>

The <b class='cmd'>install</b> command does the following:

<p>
<ul>
<li>

Builds a list of the options explicitly included in the <b class='cmd'>install</b>
command -- in this case, <strong>-foreground</strong>.

<br><br>
<li>

Queries the option database for all options delegated explicitly to
the named component.

<br><br>
<li>

Creates the component using the specified command, after inserting
into it a list of options and values read from the option database.
Thus, the explicitly included options (<strong>-foreground</strong>) will override
anything read from the option database.

<br><br>
<li>

If the widget definition implicitly delegated options to the component
using <b class='cmd'>delegate option *</b>, then Snit calls the newly created
component's <b class='cmd'>configure</b> method to receive a list of all of the
component's options.  From this Snit builds a list of options
implicitly delegated to the component that were not explicitly
included in the <b class='cmd'>install</b> command.  For all such options, Snit
queries the option database and configures the component accordingly.

</ul>

<p>
<strong>Non-widget components:</strong> The option database is never queried
for <b class='cmd'>snit::type</b>s, since it can only be queried given a Tk widget
name.

However, <b class='cmd'>snit::widget</b>s can have non-widget components.  And if
options are delegated to those components, and if the <b class='cmd'>install</b>
command is used to install those components, then they will be
initialized from the option database just as widget components are.

<p>

<h3><a name="macros_and_meta-programming">Macros and Meta-programming</a></h3>
<p>

The <b class='cmd'>snit::macro</b> command enables a certain amount of
meta-programming with Snit classes.  For example, suppose you like to
define properties: instance variables that have set/get methods.  Your
code might look like this:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::type dog {
        variable mood happy

        method getmood {} {
            return $mood
        }

        method setmood {newmood} {
            set mood $newmood
        }
    }
</pre></td></tr></table></p>
 
That's nine lines of text per property.  Or, you could define the
following <b class='cmd'>snit::macro</b>:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::macro property {name initValue} {
        variable $name $initValue

        method get$name {} &quot;return $name&quot;

        method set$name {value} &quot;set $name \$value&quot;
    }
</pre></td></tr></table></p>

Note that a <b class='cmd'>snit::macro</b> is just a normal Tcl proc defined in
the slave interpreter used to compile type and widget definitions; as
a result, it has access to all the commands used to define types and
widgets.

<p>

Given this new macro, you can define a property in one line of code:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::type dog {
        property mood happy
    }
</pre></td></tr></table></p>

Within a macro, the commands <b class='cmd'>variable</b> and <b class='cmd'>proc</b> refer to
the Snit type-definition commands, not the standard Tcl commands.  To
get the standard Tcl commands, use <b class='cmd'>_variable</b> and <b class='cmd'>_proc</b>.

<p>

Because a single slave interpreter is used for compiling all Snit
types and widgets in the application, there's the possibility of macro
name collisions.  If you're writing a reuseable package using Snit,
and you use some <b class='cmd'>snit::macro</b>s, define them in your package
namespace:

<p><table><tr><td bgcolor=black>&nbsp;</td><td><pre class='sample'>    snit::macro mypkg::property {name initValue} { ... }

    snit::type dog {
        mypkg::property mood happy
    }
</pre></td></tr></table></p>

This leaves the global namespace open for application authors.

<p>

<h2><a name="caveats">CAVEATS</a></h2>
<p>

Please understand that while Snit is well-tested and fairly stable,
it is still evolving (we have not yet reached Snit 1.0).
If you have problems, find bugs, or new ideas you are hereby cordially
invited to submit a report of your problem, bug, or idea at the
SourceForge trackers for tcllib, which can be found at

<a href="http://sourceforge.net/projects/tcllib/">http://sourceforge.net/projects/tcllib/</a>.

The relevant category is <em>snit</em>.

<p>

Additionally, you might wish to join the Snit mailing list;
see <a href="http://www.wjduquette.com/snit">http://www.wjduquette.com/snit</a> for details.

<p>

One particular area to watch is using <b class='cmd'>snit::widgetadaptor</b> to
adapt megawidgets created by other megawidget packages; correct
widget destruction depends on the order of the &lt;Destroy&gt; bindings.
The wisest course is simply not to do this.

<h2><a name="known_bugs">KNOWN BUGS</a></h2>
<p>

<ul>
<li>

Error stack traces returned by Snit are extremely ugly and typically
contain far too much information about Snit internals.

<br><br>
<li>

Also see the SourceForge Trackers at
<a href="http://sourceforge.net/projects/tcllib/">http://sourceforge.net/projects/tcllib/</a>, category <em>snit</em>.

</ul>


<h2><a name="history">HISTORY</a></h2>
<p>

During the course of developing Notebook
(See <a href="http://www.wjduquette.com/notebook">http://www.wjduquette.com/notebook</a>), my Tcl-based personal
notebook application, I found I was writing it as a collection of
objects.  I wasn't using any particular object-oriented framework; I
was just writing objects in pure Tcl following the guidelines in my
Guide to Object Commands
(see <a href="http://www.wjduquette.com/tcl/objects.html">http://www.wjduquette.com/tcl/objects.html</a>), along with a
few other tricks I'd picked up since.  And though it was working well,
it quickly became tiresome because of the amount of boilerplate
code associated with each new object type.

<p>

So that was one thing--tedium is a powerful motivator.  But the other
thing I noticed is that I wasn't using inheritance at all, and I
wasn't missing it.  Instead, I was using delegation: objects that
created other objects and delegated methods to them.

<p>

And I said to myself, &quot;This is getting tedious...there has got to be a
better way.&quot;  And one afternoon, on a whim, I started working on Snit,
an object system that works the way Tcl works.  Snit doesn't support
inheritance, but it's great at delegation, and it makes creating
megawidgets easy.

<p>

If you have any comments or suggestions (or bug reports!) don't
hesitate to send me e-mail at <a href="will@wjduquette.com">will@wjduquette.com</a>.  In addition,
there's a Snit mailing list; you can find out more about it at the
Snit home page (see <a href="http://www.wjduquette.com/snit">http://www.wjduquette.com/snit</a>).

<p>


<h2><a name="credits">CREDITS</a></h2>
<p>

Snit has been designed and implemented from the very beginning by
William H. Duquette.  However, much credit belongs to the following
people for using Snit and providing me with valuable feedback: Rolf
Ade, Colin McCormack, Jose Nazario, Jeff Godfrey, Maurice Diamanti,
Egon Pasztor, David S. Cargo, Tom Krehbiel, Michael Cleverly, 
Andreas Kupries, Marty Backe, Andy Goth, Jeff Hobbs, and Brian
Griffin.  If I've forgotten anyone, my apologies; let me know and
I'll add your name to the list.




<h2><a name="keywords">KEYWORDS</a></h2>
<p>
BWidget, C++, Incr Tcl, Snit, adaptors, class, mega widget, object, object oriented, type, widget, widget adaptors
<h2><a name="copyright">COPYRIGHT</a></h2>
<p>
Copyright &copy; 2003-2005, by William H. Duquette<br>
</body></html>