I. Szczesniak wrote:
> On 5/28/08, Garrett D'Amore <gdamore at sun.com> wrote:
>
>> Sorry, one more set of questions:
>>
>>
>> >
>> > This project is an amendment to the Korn Shell 93 Integration project
>> > update 1 ARC case (PSARC/2008/094) specifying the following additional
>> > interfaces:
>> > 1) Update of ksh93 from upstream release ast-ksh.2007-12-15 to
>> > ast-ksh-2008-05-22
>> > 1.1) Update of ksh93
>> > 1.2) New "typeset" variable storage qualifier for function
>> > 1.3) New floating-point datatype "hexfloat" ("typeset -X varname)
>> > 1.4) New reserved options for "typeset".
>> > 1.5) New ksh93 math functions "ceil":
>> > 1.5) New reserved builtin "enum"
>> >
>> >
>>
>>
>> As you now have created a new keyword and function name, ("ceil" and
>> "enum"), what will happen to scripts that may already have used these words?
>>
>> Have the upstream providers given thought to dealing with changes like
>> this and their impact on already-deployed scripts? (Maybe there aren't
>> any that we care about yet, since our ksh93 is still so new.)
>>
>> I'm concerned, going forward, as ksh93 syntax becomes more prevalent,
>> that bringing in changes like the above may have unintended consequences
>> in scripts or even ON delivered components, which we cannot easily find
>> or test.
>>
>> It would be nice (and maybe this is advice to send upstream) if there
>> was a way for script authors to be sure that their namespace was not
>> going to change underneath them. As one possible solution (and this is
>> just for illustrative), imagine a flag for ksh, -N2008.05.28, which
>> script authors could put in their #!/usr/bin/ksh line which ksh would
>> take to mean that only the language features available in ksh version
>> 2008.05.28 should be exported.
>>
>> Another solution, might be to reserve some portion of the namespace
>> (e.g. with a prefix identifier such as an underscore)
>>
>
> Such as __sun_ksh_93__.2008.05.28__namespace__.____LONG DESCRIPTION____.enum?
>
That's kind of ridiculous. But, I suppose script developers could
contrive such a name. It wouldn't be hard for the ksh93 maintainers to
offer a shorter prefix (such as a single character) which was guaranteed
never to be unique, though.
> I am sorry, this doesn't make sense. No one asked the bash port
> maintainers to do this when bash added features in 3.2 and Sun updated
> to 3.2 last year. Or Python. Or JAVA.
>
That's true, in part.
For Java and Perl at least, we have had to offer backwards compatibility
versions for a while. There was a multi-year transition effort
surrounding the significant Java upgrade from 1.4 to 1.6. (Note that
minor updates, which don't add keywords, don't have the same concerns.)
Nobody has seriously proposed that bash be used as a programming
language -- or at least -- nobody at Sun has proposed that it should be
used as a "preferred" programming language. And I believe bash is given
an External stability level, to boot -- so we (Sun) make no promises
about its stability one way or the other.
ksh93 on the other hand has, IIUC, and increased level of
stability/commitment, and as we seem to be encouraging developers to
shift to it from older /bin/sh or ksh88 scripting, it seems like we
should do more to prevent breakage here when we can.
I'm not familiar with the details surrounding Python -- the Python man
page makes no claim about stability (which IMO is a bug).
>
>> for either new
>> names in the language, or to reserve it for script author use (e.g.
>> names with a certain prefix are guaranteed to be "safe".)
>>
>
> It was always good practice to avoid C language keywords in shell
> scripts. Quoting the Opensolaris programming style guide:
> Do not use function names which are reserved keywords (or function
> names) in C/C++/JAVA or the POSIX shell standard (to avoid confusion
> and/or future changes/updates to the shell language).
>
While the advice seems sound, that document carries no weight outside of
code integrating into ON though. In particular, we are not offering
that advice (or at least haven't done so anywhere I'm familiar with) to
end users.
It also seems like we should publish the full list of such keywords in
the same place that we offer this advice, since shell scripters may not
know the various reserved words in languages they do not know.
-- Garrett
