You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).The text was updated successfully, but these errors were encountered: