Proposal: Property Accessor Function Shorthand

Bob Myers rtm at gol.com
Mon Nov 25 05:17:07 UTC 2019


This is a great proposal which I hope can attract the support of the powers
that be. The arrival of optional chaining seems to indicate a renewed
interest in optimizing the way properties are accessed--which after all is
a big part of what JS does for a living.

Using `.a` to denote a function to retrieve the value of the property named
`a` was actually part of an earlier proposal for a number of ways to extend
dot notation. I won't link to that proposal since it's obsolete now, but it
also allowed

```
const getFirstName = .name.first;
```

With optional chaining syntax, this would presumably also be able to be
written as `.name?.first`.

The earlier proposal also suggested extending this notation to arrays, so
that

```
const head = .[0];
```

In case you are interested, the current version of the proposal for
extended dot notation limits itself to accessing multiple properties with
the syntax `.{a, b}`. It can be found at
https://github.com/rtm/js-pick-notation/.

FWIW, the syntax `.propName` does appear to be syntactically unambiguous.

--
Bob

On Sun, Nov 24, 2019 at 4:51 PM <sup at aguz.me> wrote:

> Hi folks! I'd like to hear your feedback on a proposal idea I have and
> that I couldn't find anything on. Here is what I have so far.
>
> With the rising popularity of functional programming patterns in
> JavaScript, functions that take an object and return the value of a
> property are ubiquitous. These are some popular examples:
>
> ```js
> // filtering by a boolean property
> const activeProducts = products.filter(product => product.active);
>
> // mapping
> const productNames = products.map(product => product.name);
>
> // sorting, grouping, etc
> const sortedProducts = _.sortBy(products, product => product.name);
> const { true: activeProducts, false: inactiveProducts } = _.groupBy(
> products,
> product => product.active
> );
> ```
>
> This pattern is so common in fact that libraries like `lodash` (and
> frameworks) often also accept passing the name of the property as a string:
>
> ```js
> const sortedProducts = _.sortBy(products, "name");
> ```
>
> However, this technique has various problems:
>
> 1. It requires extra code from the library authors. With its typical
> disadvantages.
> 2. It has a potential negative impact on performance.
> 3. It is not easily statically analyzable, which makes it hard to
> type-check, infer, and for tooling to catch typos.
>
> Several languages have solved these problems by introducing some syntactic
> sugar that simplifies the definition of these functions. My favorite
> example is Elm's: `.property` shorthand [1]. If JavaScript supported this
> syntax, we could write the previous examples as:
>
> ```js
> const activeProducts = products.filter(.active);
> const productNames = products.map(.name);
> const sortedProducts = _.sortBy(products, .name);
> const { true: activeProducts, false: inactiveProducts } =
> _.groupBy(products, .active);
> ```
>
> This is, in my opinion, nice to read and write. Besides, since this
> expression simply yields a function, it would not have any of the problems
> the string approach has.
>
> Combined with the pipeline operator proposal, it would allow code like the
> following:
>
> ```js
> orders
>   |> filter(.active)
>   |> flatMap(.products)
>   |> .length
> ```
>
> Lastly, engines might be able to optimize this further (or more easily)
> than normal functions since functions defined this way would be restricted
> to returning a constant property of the object that is passed to them. They
> would not be able to have any other expressions or statements in them.
> Unfortunately, they would not be considered automatically pure because
> users can implement side effects in property getters or Proxies.
>
> I could not think of any syntax ambiguity this could cause, but I would
> appreciate your thoughts in this regard. It does look similar to the RHS of
> a Member Expression, but it would not be ambiguous because the two would
> not be allowed under the same contexts. The F# community has had an
> interesting ongoing conversation [2] about the topic, but it is my
> understanding we would not have these problems in JavaScript since Call
> Expressions require parenthesis.
>
> [1] https://elm-lang.org/docs/syntax#records
> [2] https://github.com/fsharp/fslang-suggestions/issues/506
>
> I am looking forward to hearing your feedback!
>
> Agustín Zubiaga
> Head of Engineering @ PINATA
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20191124/4a827b89/attachment.html>


More information about the es-discuss mailing list