From: Will Duquette <will@wjduquette.com>
Date: May 31, 2004 9:25:14 AM PDT
To: snit-wjduquette.com@lists.wjduquette.com
Subject: [Snit] Snit Reconsidered #7: Option Definition Syntax

This is the seventh in a series of essays pondering the design of Snit
1.0.

This essay describes a new design for option definition.  Please let me
know what you think--if you like it, dislike it, or even if you don't care
one way or another.

At present a full Snit option definition, complete with onconfigure and
oncget handlers, looks something like this:

    option {-myoption myOption MyOption} initialValue

    onconfigure -myoption {value} {
        # Some kind of processing or validation
        set options(-myoption) $value
    }

    oncget -myoption {
        # Some kind of processing
        return $options(-myoption)
    }

There are several things I dislike about this syntax.

* It's not particularly concise: it takes three distinct type definition
  statements to full define an option, and you have to repeat the option name
  in each.

* It's not easily extensible: the "option" command uses positional syntax,
  and so doesn't lend itself to additional arguments.

Here's an alternate syntax I've been thinking about:

    option {-myoption myOption MyOption}    \
        -default     initialValue           \
        -onconfigure { set options(%o) %v } \
        -oncget      { return $options(%o) }

In the handlers, the following replacements would be made:

    %o      the option name
    %r      the option's option database resource name
    %c      the option's option database class
    %v      the new value

This syntax has the advantage that it's naturally extensible; we can
always add more options.  For example, in my application code I often
define options that can be set only at creation time.  You can write
an onconfigure handler to do that, but this is easier:

    option {-myoption myOption MyOption} \
        -readonly yes

And no doubt there are other options we'd want to add over time.

Now, a question: the reason I originally chose to make onconfigure a separate
statement was the handling of the value argument.  In

    onconfigure -myoption {value} {
        set options(-myoption) $value
    }

it's clear from the syntax where the new value comes from; it's just an
argument.  This seemed less obscure to me.  The new syntax is more terse,
but it's also more obscure.  Is that a problem?

-------------------------------------------------------------
       will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com | The View from the Foothills

_______________________________________________
Snit mailing list
Snit@lists.wjduquette.com
http://lists.wjduquette.com/listinfo.cgi/snit-wjduquette.com