Extended dot notation (pick notation) proposal

Bob Myers rtm at gol.com
Sat Oct 1 01:24:57 UTC 2016

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.

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/20161001/8206ac19/attachment.html>

More information about the es-discuss mailing list