Open dlespiau opened 5 years ago
Just to set out some trade-offs:
Given that the standard library is built into the runtime, its contents will be static for a particular release. So the sense in the which this is future-proof is that it doesn't need to be adjusted in the jk source code when a named export is added to std -- and not (as might initially seem the case) that the runtime will automatically pick up new capabilities when things are added to the standard library.
It makes inline scripts a little more wordy, because they'll have to include std.
when referring to things from std (this can be regarded as a positive too)
scripts that try to use things not in std
can fail in less obvious ways. For example, if I try to use std.format
instead of std.Format
as a value, the script will run and I'll (probably) get an unexpected output; whereas, if I try to use format
instead of Format
, the script will fail to compile.
Extracted from #188.
We currently import specific symbols from std in the inline template (
log
,write
,read
) we could, instead, do:so we don't miss symbols (such as
Format
) and are future (eg. I'd like to add alogerr
that outputs to stderr).