Closed springcomp closed 2 years ago
I am concerned this is beginning to conflict with the guiding principle of "one way to do something".
Can anyone suggest what other functionality that syntax could represent that we will be forgoing with this implementation?
I can see {x,y}
being a set syntax that results in a list with de-duplicated values (x=1, y=1: {x,y}=>[1]). I would also argue that this example should be implemented as a set()
function.
Compact syntax for multi-select-hash
Abstract
This JEP proposes a grammar modification to support ES6-style compact
multi-select-hash
constructs.Motivation
Consider the following JSON document:
Let’s say we wanted to return a hash containing
id
s andfirst
names. This is currently possible using the following syntax:Since
{x:x, y:y}
is such a common pattern, ES6 introduced compact object literal notation to simplify this. In ES6,{x,y}
is equivalent to{x:x, y:y}
.This JEP supports this syntax to make JMESPath usage slightly less verbose.
Specification
What is currently the
multi-select-hash
production will be renamed tomulti-select-hash-keyval
:The
multi-select-hash
production will be modified slightly to accomodate the syntax changes:The new
multi-select-hash-key
production is defined like so:Here is the full update to the grammar:
Motivating Example
With these changes defined, the expression in the “Motivation” section can be be written as:
Which evaluates to
[{"id": 1, "first": "Bill"}, {"id": 2, "first": "Larry"}]
.Rationale
This JEP is inspired by an idea from Dan Vanderkam.