-
Notifications
You must be signed in to change notification settings - Fork 447
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
Dictionaries with no sense of self #220
Comments
I usually give them descriptive names so instead of To be clear, what you're proposing is a syntax sugar:
desugared via this rule: to
which would manifest as:
|
Assuming {{ }} is the syntax, which is probably unwise because of templating languages and their predilection for {{ }} |
Note that this is exactly how ES6 arrow functions work (as compared to regular JS functions). |
Technically, yes, but the presence of self binding in an object is significantly more legitimate / expected than in a closure. |
Right. I meant that JS functions have a "this" binding in them (similar to JSonnet objects), which is very inconvenient (one has to use f.bind(this)). Your proposed sugar is similar to what ES6 tries to achieve with ()=> functions, which don't have a "this" binding, and thus capture one from the outer scope. |
I would secretly be pleased if jsonnet used {{}} in its grammar, because it would discourage the use of text templating tools to generate jsonnet code ;-) |
* Add test support for multi-file output. * Add -update support for multi-file output tests. * Add support for string output in multi-file output mode. * Rename 'stringOutput' to 'stringOutputMode' to better express what it does * Refactor main_test to make it less nested. This also causes the -update flag to output a list of files which have been updated. This does not include the paths which are deleted for multi-file tests.
I find that most of the time I'm writing jsonnet, having an object bring a magic
self
into scope is a bit of a pain. I usually end up having to define alocal realSelf = self
in the outer scope to retain theself
that I actually wanted.Can we have raw dictionaries with no magic
self
in scope for those times we just want to operate on a pure datastructure?This is almost the opposite of the
rec
keyword in Nix. For context,rec
brings a dictionary's keys into scope within that dictionary, and the default is to have no access to the equivalent ofself
. I'm not proposing changing the default at this stage, but it would be nice to have a way to opt out.cc @roconnor, since whenever I mention Nix @sparkprime cc's him anyway 😄
The text was updated successfully, but these errors were encountered: