-
Notifications
You must be signed in to change notification settings - Fork 257
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
Pain Point: Deeply Nested Amends (No Flat Member Syntax) #423
Comments
We'd like to add support for flat member syntax (the solution that you suggested) at some point. I definitely agree that this a pain point. |
That's great to hear, and thanks for the quick response! Feel free to change the title to something more suitable for tracking flat member syntax. Fwiw, Pkl has been fantastic for me, and I often find myself telling people how amazing it is :) |
|
Actually, the
Is that the same as
or
That has implications for what Or... should that ambiguity should syntactically be disallowed and should this require that properties are aggregated in notation, i.e.
|
In both of those cases, An interesting problem here is what
Another one is this:
It would be surprising if it expands to the below snippet, because in the below snippet, the
|
Distinguishing |
I see your point, but I'm not very convinced that this is a problem. This is unambiguous without needing lookahead:
This does require lookahead (because
But:
Before shipping this feature, we'd definitely need to play around with this syntax in real world code. |
Arbitrary lookahead can cause problems with syntax highlighters and parser tools. It can also cause performance issues. It’s best avoided if possible.
I think that’s only the case because typed objects can’t have elements and entries. Is this limitation here to stay?
I think it’s best to avoid such assumptions when designing a feature. If the feature can be used inside objects, it will be used inside objects. |
No, it's because expressions are not permitted at the module level. And, this isn't likely to change. |
But if typed objects could have elements, it would make a lot of sense to allow expressions (elements) at the module level. This would also work great for rendering formats that support top-level arrays (JSON, etc.). Same for entries. |
This might be a good first (and possibly last) step. Good editor support could ease the strictness pain. Definitely worth prototyping.
Sounds like a simple expansion won't be good enough. |
Even if typed objects eventually allow entries and elements, I'm kind of bearish on this at the module level. This starts to feel too much like a scripting language: module foo
something()
somethingElse() The way to render top-level arrays is to assign to someListing: Listing<String> = new { "hello" }
output {
value = someListing
renderer = new JsonRenderer {}
}
Yeah; we need to explore what the scoping rules should be. And, it might require that we start resolving variables at parse-time (within |
I'm testing Pkl as a replacement for k8s tools like Kustomize/Helm. So far it's quite nice, but one pain point is modifying deeply nested properties.
As an example, say I have a HomeAssistant pkl package with a default volume claim of 1Gi, which I'd like to bump up to 2Gi.
18 LoC for a single deeply nested amendment seems a little excessive.
One way I've found to improve this is to remove some newlines, but I don't find this ideal.
I could create late-binding variables in a new pkl module which extends
ha-app
further, but that seems like I'd just be moving the problem down the line.Personally I'd like to see dot syntax supported for amendments. In my case, that might look something like:
Am I missing a more idiomatic solution?
The text was updated successfully, but these errors were encountered: