Re: [PATCH] Proposal: stat -> zstat

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On May 8,  3:40pm, Peter Stephenson wrote:
}
} In my reply to Phil I suggested using a convention like b:zstat,
} p:functions, f:sin, c:-pcre-match, etc., to get around namespace
} problems. It's quite possible we don't have clashes at the moment,
} but it's entirely conceivable a module may export both a builtin
} and a parameter with the same name. I think ":" is a good choice
} here---doesn't need quoting, used in a similar way for styles---but
} I'd be happy to entertain alternatives.

I agree that ":" is a good choice; "." is the other obvious possibility,
but we probably want to reserve that for ksh-style parameter namespaces.

} This ought to be transparent to the main shell; it just passes down a
} feature name to be handled by the module...

Right.

} Suppose:
} 
} zmodload -ab zsh/nosh fishfingers
} 
} is defined to be equivalent to
} 
} zmodload -Fa zsh/nosh b:fishfingers

This makes perfect sense.

} and we document that the the second form is preferred? In other words,
} the -a addition to the feature mechanism *does* require the name to
} be in the form <codechar>:<featurename>, and generates an autoload
} request of the appropriate type (or an error if it doesn't recognise
} the prefix).

This is also related to the question of whether a module feature can
represent a collection of things.  Could

  zmodload -Fa zsh/nosh turtleteeth

mean e.g. "autoload anything related to turtleteeth"?  I suppose that
would mean loading zsh/nosh immediately, but with everything disabled,
in order to find out what is contained in that feature.  (And then
unloading it again?  Hrm.)  Or else abstract features are in their
own category, but then how do you know when to autoload them?  For the
first pass, or even the second, perhaps abstract features should not
be auto-loadable.

Which brings up a point:  Previously modules were either all there or
all not, except insofar as certain bits could be hidden by explicitly
using "disable" after loading.  With the features change we can get
into the condition of the module being present, but invisible.

} One extra tweak at least is needed: if we loaded a module through the
} new form of autoload, we only enable any features explicitly requested
} in that list.  For compatibility the old form would fully load the
} module (it may well be that a function assumes that autoloading one
} builtin will bring in a whole load of others).

What happens if both -Fa b:turtleteeth and -ab turtleteeth have been
executed prior to the first attempt to find turtleteeth?  The easy way
out is to do the maximal load that has been previously requested.

Random possibly unrelated thought:
We might want to think ahead to the possibilty of module scopes (like
the local parameter scope).

} Presumably
} 
} zmodload -ab zsh/nosh b:fishfingers
} 
} should generate an error

Since ":" isn't valid in an identifier I think that's OK.  (Have we yet
discussed whether symbolic conditionals like "=~" could be autoloaded?)

} > Can features (or the user, with zmodload -d) declare that they
} > depend on other features (of the same or other modules)?
} 
} Urk. The current dependency mechanism is per-module and if we're going
} to keep it then to do it properly we need it to be per-feature. If
} each *feature* in the target module can depend on a feature in another
} module it gets very hairy even to specify.

I'm actually most concerned with the C definition of the module being
able to specify dependencies, rather than the user being able to do so
with some tangled zmodload -d syntax.

} Although this is a significant question, I think we could implement
} module features without this initially

Yes.