From: Will Duquette <will@wjduquette.com>
Date: May 12, 2004 8:20:39 PM PDT
To: snit@lists.wjduquette.com
Subject: Snit Reconsidered #5: Option Handling Issues

This is the fifth essay in a series on the design and implementation of
Snit.

The purpose of this essay to point out some problems with how Snit
handles options rather than propose solutions.  I expect to write further
on each of these topics, but I'm rather hoping to get some feedback first.

* The option delegation syntax suffers from the same problems I discussed
  with regard to method delegation.  The syntax is "pseudo-English", not
  a good thing; also, it's not possible to delegate options to anything
  that isn't explicitly widget-like.  Text tags and objects in canvas
  widgets have options, but Snit can't (at present) delegate to them.

* An option can't be delegated to multiple components, i.e., you can't
  delegate a single -labelfont option to all label components.  In this
  case, though, I'd argue that delegation is the wrong model.  The option
  is really a local option, owned by the object itself, that happens to
  be propagated to a number of components.

* When a widget option's value is read from the Tk option database, the
  value replaces the option's default value--and hence is never validated.
  This is a potential source of errors, and there's no easy solution given
  the current implementation.

* The option definition syntax is ugly.  Defining an option with
  an onconfigure handler and an oncget handler takes a minimum (following
  the usual style) of 9 lines of code.  Add some comments to bind the
  whole thing together, and it becomes longer still.

  option -myoption

  onconfigure -myoption {value} {
      # Do something
  }

  oncget -myoption {
      # Return something
  }

  Also, there's no way to write code to validate an option except in an
  onconfigure handler, which means that there's no way to validate a
  value without actually setting the option's value.  I'd like to add a
  validation command, and I'd like to combine all of the above (and
  possibly a propagation feature, all into a single statement.

* When I was first implementing it, the "options" array made a lot of
  sense.  I suspect that it still makes a lot of sense.  On the other
  hand, I find that I often end up copying option values into other
  instance variables because

    $myoption

  is a lot easier to type than

    $options(-myoption)

  Should I leave the options array as it is?  Or should the value of
  each option "-myoption" be saved in an instance variable "myoption"?

* Quite some time ago, someone suggested that Snit needed a simple way
  to define public access methods for instance variables, e.g.,

  % snit::type dog {
      variable breed labrador

      # Some magic statement to create an access method
  }
  ::dog
  % dog fido
  ::fido
  % fido breed
  labrador
  % fido breed dachsund
  dachsund
  % fido breed
  dachsund

  If I got rid of the options array, as described above, then any
  instance variable could be turned into an option; and the option
  definition could indicate whether to create the access method or
  not.  For snit::widgets, you usually wouldn't; for snit::types
  you might.

I'm greatly interested in any comments, and also any issues others
might have.

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