The problem is the same unless you have a way of "gluing" an expression as
a "shorthand-function" e.g. `:.prop1 / :.prop2` won't be interpreted as a
single function that performs x.prop1 / x.prop2, but rather an attempt to
perform division with 2 functions

On Wed, 26 Jun 2019 at 10:44, Michael Luder-Rosefield <
rosyatran...@gmail.com> wrote:

> The more I read this proposal, the more I feel the ideal solution is a
> preceding 'wildcard' character, to stand-in for a generic argument. If it
> wasn't in (widespread!) use, I'd suggest an underscore: ```const f = _.prop
> ```
>
> Since it is, though, we need another one. How about a double-colon, seeing
> as it can represent property access on other languages? ```const f =
> ::prop ```, ```const g = ::[compProp] ```, ```const h =  ::?optProp ```
>
> On Sun, 23 Jun 2019, 11:43 Simon Farrugia, <simonfarrugi...@gmail.com>
> wrote:
>
>> I was expecting that someone brings up the brackets property accessor at
>> some point.
>> I would argue that there is a bit of syntactic inconsistency since
>> usually when using the bracket accessors it is not preceded by a dot.
>> ```
>> const getEmail = user => user["contacts"].email; // No dot between user &
>> ["contacts"].
>> const getEmail = .["contacts"].email;
>> ```
>> Having said that, the currently proposed Optional Chaining operator
>> (Stage 2) <https://github.com/tc39/proposal-optional-chaining/> does
>> exactly that and more:
>> ```
>> obj?.prop       // optional static property access
>> obj?.[expr]     // optional dynamic property access
>> func?.(...args) // optional function or method call
>> ```
>> So I'd say that there is consistency with what is currently being
>> proposed.
>>
>> Regarding the Optional Chaining operator, which precedes the dot. How
>> would that work?
>>
>> It would have to be something like this, if allowed.
>> ```
>>
>> const getEmail = user => user?.contacts.email;
>> const getEmail = ?.contacts.email;
>>
>> ```
>>
>> It does look odd at first, but it’s quite simple is you think about it.
>> We are just omitting the initial part of the expression.
>>
>>
>>
>> More Examples with Optional Chaining operator:
>>
>> ```
>>
>> // With optional dynamic property access.
>>
>> const getUserEmail = user => user?.["contacts"].email;
>> const getUserEmail = ?.["contacts"].email;
>>
>>
>>
>> // With optional function or method call.
>>
>> const getJohnsEmail = getUserContacts =>  getUserContacts
>> ?.("John").email;
>> const getJohnsEmail = ?.("john").email;
>>
>> ```
>>
>>
>>
>> The beauty of what is being proposed is that there is nothing new to
>> learn or any new weird operator introduced.
>>
>> Any weirdness one might find with the expressions above will already have
>> been introduced by the Optional Chaining operator.
>>
>> The only thing this does is to allow you to omit the initial (redundant)
>> part of the expression.
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to