Re: [PATCH] Proposal: stat -> zstat

[Peter Stephenson <pws@csr.com>]

Bart Schaefer <schaefer@brasslantern.com> wrote:
> Perhaps what we should be thinking of is a more general utility for
> zmodload, along the lines of Perl's export-tag semantics, so that a
> module can be asked to selectively install only those bits that the
> caller needs.

How about the following.  This tries quite hard not to break anything.

Each module can advertise a set of features it supports.  These
will be variables, builtins, conditions or math functions; we'll need a
convention for how to disambiguate.  I wouldn't propose to build the
convention into the API, however, just represent each feature by a string
and rely on modules to use the convention.  This makes it extensible.

At the C API, we can then add standard module functions to query and enable
or disable features.  On most systems we can just search for appropriate
functions; on AIX there's some magic I don't yet understand turning the
standard module functions into an index, so it might be harder.  Since we
need to recompile modules for each version of the shell, this only becomes
a problem with someone else's add-on that hasn't been upgraded.

We can have one function to pass up a string list of features as an array
and the current set of enabled features, and another function to pass down
the new set of enabled features.  The default is for all features to be
enabled.

The list of features is in the same internal format as a zsh array.

The set of enabled features can be an arbitrary-length array of unsigned
integers with bits giving the enabled status.  We can explicitly limit
ourselves to the first 32 bits of each integer for future proofing.
Obviously we need one bit for each feature array element.  Alternatively,
we could use an integer array of the same length as the feature list and
declare all but the bottom bits a being for future expansion.

At the shell command API,

zmodload <module>
  loads everything (as at present).  If the module is already loaded, and
  supports features, zmodload will check to see if all features are loaded.
  If they are, it's an error.  If not, it will enable them all.
  (This is necessary to fix cases like a function looking for a builtin
  it knows is supplied by a module and loading the module if it doesn't
  find the builtin.)
zmodload -i <module>
  will load the module if it's not loaded, and enable all features.

zmodload -F <module> feature1 feature2
   will load the module or cause an error if it's already loaded,
   and turn on feature1 and feature2 (only---all others are disabled).
zmodload -iF <module> -feature1 feature3
   will load the module if it's not already loaded, turn off feature1
   and turn on feature3, leaving all other features alone.
zmodload -lF <module>
   lists all enabled features of <module>, one per line.  It returns
   status 1 (printing an error message?  or not?) if <module> is
   not loaded.
zmodload -LF <module>
   lists the zmodload commands required to turn on the currently
   enabled set of features.  This might be "zmodload <module>" if
   all features are enabled.

If you try to enable or disable a feature the module doesn't say it
supports, an error message is printed and status 1 is returned (but any
other feature change requests will be processed).

New functions that just require particular features will call "zmodload -iF
features...".  Older functions can still call "zmodload -i" and rely on
all the feature being present.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview