Re: [PATCH] Proposal: stat -> zstat

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

On 2007-05-03 at 09:50 +0100, Peter Stephenson wrote:
> Adding zstat is useful.  We could possibly still make modules that only
> use it internally disable stat if the module wasn't previously
> loaded---otherwise removing the disabling actually makes things worse.

Hrm.

Situation before:
  If zsh/stat loaded and stat enabled:
    happy days
  If zsh/stat loaded and stat disabled:
    temporarily reenable, disable with exception
  If zsh/stat not loaded and user likes builtin stat:
    gloriously happy days
  If zsh/stat not loaded and user dislikes builtin stat:
    manual-page documents work-around

Situation with my patch:
  If zsh/stat loaded and zstat enabled:
    happy days, don't touch stat
  If zsh/stat loaded and zstat disabled:
    hrm.  Why would zstat be disabled?  Perhaps worth covering, but
    nothing else works around "functions loaded but disabled" so this
    would be the exception
  If zsh/stat loaded and stat disabled:
    Fine.  We leave it that way.
  If zsh/stat not loaded and user likes builtin stat:
    gloriously happy days
  If zsh/stat not loaded and user dislikes builtin stat:
    manual-page documents work-around (same)

I'm not seeing what makes things worse.  History suggests that given
that you've claimed it does then I'm wrong and just not seeing it, so
I'd appreciate a clarification.  :^)

Now, one thing which might be useful in addition to the proposed
extended syntax for zmodload would be to add a new flag BINF_DISABLED
which actually names the (1<<0) case and offers something to go in a
module, so that a builtin table entry can per definition be disabled by
default.

So the stat documentation note could state something like:

 In the next major release of zsh, stat will still be a valid loadable
 command but it will not be enabled by default.  If you need to maintain
 a script's compatibility across different versions of zsh, then a good
 idea is to _now_ add an explicit "enable stat" after "zmodload
 zsh/stat".  In this and older releases of zsh, the explicit enable is
 harmless.  In the next major version, it will allow the script to work
 unmodified.

 If you only need compatibility with version 3.1.6 or newer, then you
 can move to zstat now and avoid introducing stat unnecessarily when the
 zsh is recent enough by using this code:

   zmodload -i zsh/parameter zsh/stat
   if [[ $builtins[stat] == defined && $builtins[zstat] != defined ]]
   then
     function zstat { builtin stat "$@" }
   fi

As an aside: I explicitly check against 'defined' instead of non-zero
since this is more resilient to *cough* people who put:
  zmodload -ab -i zsh/stat stat zstat
in a startup file unguarded by version numbers as it's "harmless".
*whistles innocently*

With documentation like this, and a phased approach to any change, I
think that it'd be fair to say that zsh still takes backwards
compatibility somewhat more seriously than some other shells I could
name.

I'm not sure how to word "next major release" to cleanly convey "the
stable release directly after, not counting patch-levels, the stable
release in which this was introduced (and if you're using zsh 4.3.x then
note that this is unstable, so we're giving you more time)".  The only
way would be to commit to explicit release version numbers.  zsh 4.4
adds zstat, 4.6 disables stat by default, 4.8 removes stat?  Or does
anyone have thoughts about a zsh 5?

Personally, I think that multibyte support is significant enough to
warrant 5.0 following 4.3.x.  At times after the EU added the Euro and I
switched to UTF-8, I found missing multibyte support a reason to do some
things in other shells.  (Why use a rarely found Latin 9 when you can
bite the bullet and switch to something more global?)

-Phil