rtm at gol.com (2016-09-21T22:18:19.116Z)
Since some people seem to find the proposed pick notation `o.{p1, p2}`, (to
create an object composed of the `p1` and `p2` properties from `o`)
confusing, I am making an alternative proposal which hews more closely to
existing deconstructing assignment.
The definition of the new syntax is:
> If a deconstructing assignment is wrapped in curly brackets `{}`, the
result is a new object where the deconstructed names and values become
property names and values.
The above case would be written as:
```
{ {p1, p2} = o }
```
and would result in
```
{ p1: o.p1, p2: o.p2 }
```
AFAICT the above syntax should be uniquely parseable.
The advantage of this syntax is the minimal cognitive footprint: if you
know how to deconstruct an object into variables using deconstructing
assignment, then you can deconstruct an object into properties on a new
object with nothing more than an extra set of surrounding curlies.
I will be adding this alternative syntax to the repo here
<https://github.com/rtm/js-pick-notation> and here
<https://github.com/rtm/js-pick-notation/blob/master/minimal/spec.md> in
the near future.
--
Bob
Since some people seem to find the proposed pick notation `o.{p1, p2}`, (to create an object composed of the `p1` and `p2` properties from `o`) confusing, I am making an alternative proposal which hews more closely to existing deconstructing assignment. The definition of the new syntax is: > If a deconstructing assignment is wrapped in curly brackets `{}`, the result is a new object where the deconstructed names and values become property names and values. The above case would be written as: ``` { {p1, p2} = o } ``` and would result in ``` { p1: o.p1, p2: o.p2 } ``` AFAICT the above syntax should be uniquely parseable. The advantage of this syntax is the minimal cognitive footprint: if you know how to deconstruct an object into variables using deconstructing assignment, then you can deconstruct an object into properties on a new object with nothing more than an extra set of surrounding curlies. I will be adding this alternative syntax to the repo here <https://github.com/rtm/js-pick-notation> and here <https://github.com/rtm/js-pick-notation/blob/master/minimal/spec.md> in the near future. -- Bob On Thu, Sep 8, 2016 at 10:58 PM, Bob Myers <rtm at gol.com> wrote: > > I just find the syntax confusing > > It combines two syntaxes we know and love: (1) dot notation `o.b` and (2) > deconstructing notation `{a} = o`, into `o.{a}`. > > Maybe some have problems with the dot in `a.{o}` being too inconspicuous. > At the cost of using up a precious special character, we could go with `o # > {a}` instead. Actually I think `o pick {a}` is syntactically unambiguous. > > > I do like the idea of building a way of taking a portion of an object > out of one object and into another > > Good, many people seem to agree. > > > Why couldn't this be an Object.pick() > > Personally, passing around properties as strings grates on me. Then > there's the issue of typability, although Isiah has pointed out a useful > TypeScript proposal that does deal with that. Within the `_.pick` paradigm, > it's hard to envision a concise syntax for defaults and renaming, which the > deconstructing-like syntax gives us for free. > > > It could even be expanded to handle deep nesting > > Just curious, what sort of interface to your `_.pick`-like thing do you > have in mind>? Will it support defaults and renaming? > > By the way, I was looking at Elm and found it supports one advanced > feature of extended dot notation, which is the unary dot as function, as in > `arr.map(.p)`. > > Bob > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160915/8206ac19/attachment.html>