Re: [PATCH] Proposal: stat -> zstat

[Peter Stephenson <pws@csr.com>]

Bart Schaefer wrote:
> This is also related to the question of whether a module feature can
> represent a collection of things.  Could
> 
>   zmodload -Fa zsh/nosh turtleteeth
> 
> mean e.g. "autoload anything related to turtleteeth"?  I suppose that
> would mean loading zsh/nosh immediately, but with everything disabled,
> in order to find out what is contained in that feature.  (And then
> unloading it again?  Hrm.)  Or else abstract features are in their
> own category, but then how do you know when to autoload them?  For the
> first pass, or even the second, perhaps abstract features should not
> be auto-loadable.

That last suggestion is likely to be the case.  It's hard to think of a
general mechanism where the shell would know what autoloading an abtract
feature means.  It may be best done (a little like Emacs' hooks) with
a shell function that simply sets up regular autoloads for any concrete
features.

> Which brings up a point:  Previously modules were either all there or
> all not, except insofar as certain bits could be hidden by explicitly
> using "disable" after loading.  With the features change we can get
> into the condition of the module being present, but invisible.

Yes, but there still there to zmodload, so it's detectable.  An option
to unload automatically when all features are disabled isn't difficult,
I don't think; it can be done locally in the main shell's feature
handler.  This should be transparent to future feature requests, and
easy to add later on.

> What happens if both -Fa b:turtleteeth and -ab turtleteeth have been
> executed prior to the first attempt to find turtleteeth?  The easy way
> out is to do the maximal load that has been previously requested.

Yes, that shouldn't be too hard.

> Random possibly unrelated thought:
> We might want to think ahead to the possibilty of module scopes (like
> the local parameter scope).

It's quite hairy to define what the scope is, and also pretty hairy to
implement it since builtins, math functions and conditions don't have a
scope at the moment.

> } Presumably
> } 
> } zmodload -ab zsh/nosh b:fishfingers
> } 
> } should generate an error
> 
> Since ":" isn't valid in an identifier I think that's OK.  (Have we yet
> discussed whether symbolic conditionals like "=~" could be autoloaded?)

That needs some tweaking in the main shell; I vaguely feel leaving
them in the form of -special-tests and not polluting the normal
shell syntax might be preferable.

> I'm actually most concerned with the C definition of the module being
> able to specify dependencies, rather than the user being able to do so
> with some tangled zmodload -d syntax.

Internally this is similar, but deciding what the dependencies actually
are is probably messier in general; since, as I said, we typically
need all of a service module for the next level up this doesn't seem
to arise yet.

-- 
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