Proposal: Property Accessor Function Shorthand

sup at aguz.me sup at aguz.me
Mon Nov 25 17:54:43 UTC 2019


Hi Bob! I’m glad you like the proposal!

> 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;
> ```

Going multiple levels deep and using optional chaining certainly sounds appealing. However, I'm a little concerned with the ramifications of supporting that syntax.

```js
.name.first
```

could also mean

```js
((u) => u.name).first
```

The former is undoubtedly more useful, and it would probably have precedence, but it makes parsing and reading harder.
Also, once you support this, it makes it seem like the first dot is a placeholder for the first argument, and then shouldn't the following be allowed too?

```js
// calling functions
const names = products.map(.details.getName());
// or even
const doubled = [1, 2, 3, 4].map(. * 2);
```

That's interesting, but it goes beyond the goals of this proposal. That being said, I’m more than open to discuss this aspect, if folks think this is how it should be.

> The earlier proposal also suggested extending this notation to arrays, so that
>
> ```
> const head = .[0];
> ```

I would definitely like it support this, though :)

--

Agustín Zubiaga | Head of Engineering @ PINATA
On Nov 25, 2019, 12:17 AM -0500, Bob Myers <rtm at gol.com>, wrote:
> 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/20191125/dfb7e34d/attachment-0001.html>


More information about the es-discuss mailing list