Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: [PATCH] Proposal: stat -> zstat

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,

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.


Messages sorted by: Reverse Date, Date, Thread, Author