I agree that it would be good to have use cases.
@ngalbraith is also right that not everyone is writing their CF code based on
naked netCDF access. Indeed, I consider such an approach foolish, since CF is
far too rich by now to stand a series chance of getting it right.
However, while using the netCDF variable name as a program variable name might
be excused in small, not reused code that only ever will deal with, say `tas`,
it is inexcusable in general-purpose library code. How would such a variable
enter the namespace without the program knowing its name beforehand?
Ultimately, the only way is via the equivalent of `eval(var_name)`. Such code
is prone to breakage no matter what restrictions we put on the character set
since it would always leave open the possibility of having reserved words of
the particular programming language as variable names. Another serious problem
is that it opens the possibility to maliciously crafted variable names: How
about `var_name='system("rm -rf .")'`?
Hence, I don't think the argument that all netCDF variable names should be
permissible program variable names in all programming languages should guide
the design of CF.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-580147380
This list forwards relevant notifications from Github. It is distinct from
[email protected], although if you do nothing, a subscription to the
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to
[email protected].
