Re: [PATCH] Proposal: stat -> zstat

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2007-05-06 at 12:57 +0100, Peter Stephenson wrote:
> I'd still prefer a general solution along the lines of the feature
> mechanism, which requires (as far as I can see) no kludging or removal
> of anything, but I have had absolutely no response to that.

Well, I like it.  FWIW.

Sorry, kept quiet because I couldn't see anything wrong with the idea
and I wasn't volunteering to do the coding.  ;-)

Oh, and because I've been contaminated by Perl so I'm use to:
 use Foo::bar qw/:DEFAULT :wibble -froz/;
so your proposal fits neatly with my mental models and is actually
simpler, since it doesn't have tagged groups of things to
enable/disable.  Except insofar as the features-named-with-conventions
would let you do just that.

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.

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.

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?

Perhaps, evil thought, if feature-set changes could be tied to a
function in the same way as localoptions lets you emulate ... then this
would definitely provide cleaner start-up and functions could then just
explicitly declare their dependencies .... how much overhead would there
be for this?  I'm not sure how much complexity this introduces for
little gain.

</brain-dump><sleep>