On Mar 14, 1:46 pm, "C. G. Montgomery" <c...@[EMAIL PROTECTED]
>
wrote:
> Bruce McFarling agil...@[EMAIL PROTECTED]
wrote:
> > (snippage)
> > I do believe that *on the library side*, that is quite literally as
> > simple as possible. Its the minimum that a library can do to provide a
> > hook for automated integration into whatever Library Oversight System
> > a system may use:
> > * a name for the specification in use must be made available somehow
> I'm not sure that this is true.
This depends on context of course ... the argument is made with
respect to this context, of an open public library.
Consider if the implicit default header is made explicitly mandatory.
Then any "valid" ``fsl-utl.*'' file downloaded would have that feature
set. Then ``fsl-util.*'' is the name that can be used by the Library
Oversight System to infer whether the default header specification
applies.
If, however, it is valid to provide any implementation that offers the
higher level API, then the header implementation cannot be inferred
from the ``fsl-util.*'' filename.
If an optional default header API is specified ... even ``>standard-
header'' ... that would provide names to use to detect whether the
feature set is present ... except now a default header API is being
specified, rather than simply the structure of the default header, so
that is not simpler.
And given the simplicity of the header structure, it would seem
impossible to tell with any confidence by defining a test case and
looking ... a non-default implementation could well include that size
information in the same location relative to the address returned by
the array word, having first stored additional information in front of
that.
Since, *in this context* (not in general), the feature set cannot be
encoded and decoded, it requires a standard name of some sort. ``TRUE
CONSTANT {feature}'' is (yes, in my view) the simplest way *for a
library* to offer a standard name for a feature set.
|
