To be clear, the `. * 2` example is an exaggeration. It’d be logical to restrict it to (Optional)MemberExpressions but my point is that I think what you’re allowed to do with it is not obvious. I think this is why Elm doesn’t support it.
-- Agustín Zubiaga On Nov 25, 2019, 12:54 PM -0500, [email protected], wrote: > 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 <[email protected]>, 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 <[email protected]> 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 > > > > [email protected] > > > > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
