> > > I do find it surprising that property access isn't addressed there, > > > but it seems like it was likely just overlooked - it has no mention in > > > the repo, in the open issues, or even in the closed issues or any of > > > the open or closed pull requests. Actually, they do seem to address it here as a non-goal: https://github.com/tc39/proposal-partial-application#support-for-receiver-placeholder
If we had that, then we wouldn’t need a specific syntax for property accessors. However, arrow functions are already pretty compact, so I don’t feel a strong desire for this `receiver placeholder` syntax or something like Kotlin’s `it`. I know the same logic applies to a `property accessor` proposal, but accessing properties in JS is extremely common and in my opinion, deserving of a syntax shorthand. -- Agustín Zubiaga On Dec 7, 2019, 3:04 PM -0500, Bob Myers <[email protected]>, wrote: > Can you clarify in what sense you see this as a special case of that proposal? > To put it in very simple terms, we would like to do something like > `array.map(.name)`. > > > On Tue, Dec 3, 2019 at 3:33 AM Isiah Meadows <[email protected]> > > wrote: > > > BTW, all this is very much just a special case of this (existing stage > > > 1) proposal, and is part of why it exists: > > > https://github.com/tc39/proposal-partial-application > > > > > > I do find it surprising that property access isn't addressed there, > > > but it seems like it was likely just overlooked - it has no mention in > > > the repo, in the open issues, or even in the closed issues or any of > > > the open or closed pull requests. > > > > > > ----- > > > > > > Isiah Meadows > > > [email protected] > > > www.isiahmeadows.com > > > > > > On Tue, Dec 3, 2019 at 5:43 AM Michael Luder-Rosefield > > > <[email protected]> wrote: > > > > > > > > At the cost of adding more code, but giving more power, perhaps what we > > > > want is something akin to Kotlin's `it` keyword: > > > > https://kotlinlang.org/docs/reference/lambdas.html?_ga=2.238822404.500195435.1575368476-1345353619.1575368476#it-implicit-name-of-a-single-parameter > > > > > > > > it: implicit name of a single parameter > > > > It's very common that a lambda expression has only one parameter. > > > > If the compiler can figure the signature out itself, it is allowed not > > > > to declare the only parameter and omit ->. The parameter will be > > > > implicitly declared under the name it: > > > > ints.filter { it > 0 } // this literal is of type '(it: Int) -> Boolean' > > > > > > > > > > > > What we'd want is something concise and non-ambiguous to fulfill the > > > > same role; something that cannot currently be a valid identifier, > > > > maybe. This is the point where I start scanning the keyboard for > > > > underutilised symbols... I'm thinking the hash symbol would work. To > > > > re-use the original example: > > > > > > > > ```js > > > > const activeProducts = products.filter(#.active); > > > > const productNames = products.map(#.name); > > > > const sortedProducts = _.sortBy(products, #.name); > > > > const { true: activeProducts, false: inactiveProducts } = > > > > _.groupBy(products, #.active); > > > > ``` > > > > > > > > It makes intuitive sense in 2 ways, I think; # makes you think of the > > > > object hash you're extracting a property from, and also is familiar as > > > > something's id from CSS selectors. > > > > > > > > We could also extend it to represent multiple parameters: # is also > > > > aliased as #0, the 2nd parameter is #1, etc. > > > > > > > > Further, dynamic properties would work too: `const fooProducts = > > > > products.filter(#[foo]); > > > > -------------------------- > > > > Dammit babies, you've got to be kind. > > > > > > > > > > > > On Mon, 2 Dec 2019 at 22:32, Waldemar Horwat <[email protected]> > > > > wrote: > > > >> > > > >> On 11/24/19 9:17 PM, Bob Myers wrote: > > > >> > FWIW, the syntax `.propName` does appear to be syntactically > > > >> > unambiguous. > > > >> > > > >> It conflicts with contextual keywords such as `new . target`. > > > >> > > > >> Waldemar > > > >> _______________________________________________ > > > >> 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 > _______________________________________________ > 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
