Re: [PATCH] Proposal: stat -> zstat

[Bart Schaefer <schaefer@brasslantern.com>]

On May 3,  4:46pm, Peter Stephenson wrote:
} Subject: Re: [PATCH] Proposal: stat -> zstat
}
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Perhaps what we should be thinking of is a more general utility
} 
} How about the following.  This tries quite hard not to break anything.

This sounds very much like what I was thinking.  Some comments ...
 
} Each module can advertise a set of features it supports. These will
} be variables, builtins, conditions or math functions; we'll need a
} convention for how to disambiguate. I wouldn't propose to build the
} convention into the API, however, just represent each feature by a
} string

Do I correctly understand that the naming convention has nothing to do
with what happens when one asks that feature X of module Z be loaded or
enabled?  Your suggested -F option implies as much, but presently there
are different flags for builtins/conditions/parameters/mathfuncs.

I guess the real question is, is there any explicit interaction between
-ab/-ac/-af/-ap and -F?  Could something bad happen if I ask for a
parameter feature but say it should be loaded as a builtin?

Conversely (sort of), can features be collections of several builtins/
conditions/etc.?  Hypothetically, if I ask zmodload for the "bash-regex"
feature, do I get both the =~ condtional and the BASH_REMATCH parameter?
(I know, those aren't directly linked in the current implementation, but
I needed an example.)

} The set of enabled features can be an arbitrary-length array of
} unsigned integers with bits giving the enabled status. We can
} explicitly limit ourselves to the first 32 bits of each integer for
} future proofing. Obviously we need one bit for each feature array
} element.

I'm not following how this maps to the individual modules. Is there
one integer in the array per module, so each module is limited to 32
features?  

In any event this is an implementation detail and I'm more interested
in the shell commands.

} zmodload <module>
}   loads everything (as at present).  If the module is already loaded, and
}   supports features, zmodload will check to see if all features are loaded.
}   If they are, it's an error.  If not, it will enable them all.

I've always wondered why zmodload doesn't simply behave by default as
if the -i option were provided.  What's useful about generating an
error if the module is already loaded?

} zmodload -F <module> feature1 feature2
}    will load the module or cause an error if it's already loaded,
}    and turn on feature1 and feature2 (only---all others are disabled).

How does this interact with autoloading?  Can features (or the user,
with zmodload -d) declare that they depend on other features (of the
same or other modules)?  What happens if you try to turn off a feature
that some other feature depends on?

} zmodload -iF <module> -feature1 feature3
}    will load the module if it's not already loaded, turn off feature1
}    and turn on feature3, leaving all other features alone.

I suggest that this work like options, where a "no" prefix disables the
feature.  (Hyphens and underscores ignored like options, too.)

I'm not strongly opposed to using a leading "-" but if we do I think a
leading "+" should also be allowed.  Also, what about the -u option?
Does "zmodload -uF ..." mean anything?

That about covers it ...