Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose std in the inline jk execution #191

Open
dlespiau opened this issue May 9, 2019 · 1 comment
Open

Expose std in the inline jk execution #191

dlespiau opened this issue May 9, 2019 · 1 comment
Labels
kind/enhancement New feature or request topic/cli

Comments

@dlespiau
Copy link
Member

dlespiau commented May 9, 2019

Extracted from #188.

We currently import specific symbols from std in the inline template (log, write, read) we could, instead, do:

import * as std from '@jkcfg/std/std';

so we don't miss symbols (such as Format) and are future (eg. I'd like to add a logerr that outputs to stderr).

@dlespiau dlespiau added kind/enhancement New feature or request topic/cli labels May 9, 2019
@squaremo
Copy link
Member

squaremo commented May 9, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement New feature or request topic/cli
Projects
None yet
Development

No branches or pull requests

2 participants