-
Notifications
You must be signed in to change notification settings - Fork 2k
{+flag}, {-flag} as shorthand for {flag: true}, {flag: false} #885
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
Comments
Like the idea, but prefixing
|
Hmm, I find the postfix form a little less readable (due to spacing), and it would still be ambiguous in a curly-brace free context, since
is a legitimate way of writing |
Wasn't talking about debracability (?) there (though it's a possibility in postfix version). Observe that |
and
are both invalid expressions. Is your point that the meaning of Let's go with whichever syntax is most readable. I think that's the prefix syntax, especially when broken into multiple lines:
|
Uh, I see your point now. prefixes line well. |
Sorry, Trevor, this is a couple degrees too far golfed for my taste. I'd rather see:
Closing the ticket. |
Related: satyr/coco@457f3e9 |
It's great that
{foo}
is shorthand for{foo: foo}
, because that's a common (and awkward) construction;{option: true}
and{option: false}
are also very common, and a series of options could be made much more readable by introducing a shorthand. For instance, instead ofyou could write
I see this as a significant improvement in readability—it's much easier to check whether a particular option is enabled or disabled— as well as sheer succinctness.
Note that I'm proposing that this syntax only work inside of explicit curly braces, just as the
{foo: foo}
shorthand should only work that way (currently, no one has figured out how to implement this desired behavior).The text was updated successfully, but these errors were encountered: