Re: [PATCH] Proposal: stat -> zstat

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

Phil Pennock wrote:
> Is it worth adding to the spec that the features will be processed
> left-to-right, so that interactions between features will work?  Eg,
> disable all except certain aspects?  Most modules will never use this,
> thankfully.

For now, features are likely to mean individual features rather than
groups, but it certainly makes sense to specify they'll be parsed left
to right at the outset.

> zmodload -F zsh/pcre -:builtins :condops
> zmodload -F zsh/files :files -mv :fs
> 
> (hypothetically putting "sync" in an ":fs" category)
> 
> And yes, the : as a part of the name instead of a separator is
> distinctly un-shell-like, I use it here only so that those similarly
> afflicted will understand what I mean.

I was actually thinking of using ":" but in a different way: "b:" for a
builtin, "p:" for a shell parameter, "c:" for a condition, "m:" for a
math function, so you'd do

zmodload -Fi zsh/stat b:zstat

in the case in question.  The main reason for this is to disambiguate
the different namespaces.  It would be natural to allow

zmodload -mFi zsh/stat 'b:*'

which is very similar to existing syntax.  So I suppose that means we
could ensure that something like

zmodload -mFi zsh/stat 'b:*' -b:stat

would work (load all builtins but disable "stat").  However, explicitly
disabling things gets us back in the mess we've just climbed out
of---each chunk of code knows what it needs, and should be able to
request only those features, but doesn't know what the rest of the shell
needs or doesn't need, so should just leave those alone.  (Unless we can
come up with a rule where we take the net effect of a set of patterns
and then apply them, so that b:stat ends up being left alone.  I think
that's going to be too complicated.)

> On the other hand, arguing devil's advocate, what would the feature
> infrastructure provide that's not already available via zsh/parameters
> and use of enable/disable?

Natural integration of shell code using different features.  The disable
business, as you've already spotted, is not a very pleasant way of
getting rid of a bit you don't want, since someone else may want it
and not expect it to be disabled.  Explicit feature requests act
separately and fit together without any special action.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/