Re: Proposal Request

[Oliver Dunk]

Here! :)

> On 26 Jun 2019, at 07:20, Joseph Akayesi  wrote:
> 
> Requesting to send a proposal for a new feature in ES. Where can I share the 
> proposal?
> ___
> 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

Proposal Request

[Joseph Akayesi]

Requesting to send a proposal for a new feature in ES. Where can I share
the proposal?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Selector/Select Expression

[Simon Farrugia]

I think you are misinterpreting the intent of the proposal. It is not
intended to handle logical expressions, that's way I called it Selector
Expression :-)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Selector/Select Expression

[Simon Farrugia]

I'ld say, if there is no valid reason why a wildcard is required for the
feature to actually work we should not add any. Else we would be just be
depriving future features from using that symbol.
Also, it does start to look a bit crowded with symbols if you consider the
optional chaining operator.

Example:
```
const getUserEmail = *?.contacts.email
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Selector/Select Expression

[Naveen Chawla]

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, 
> 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)  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

Re: Re: Proposal: Selector/Select Expression

[Michael Luder-Rosefield]

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, 
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)  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