Proposal: Selector/Select Expression

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Selector/Select Expression

Brian Boyko
Howdy. First post to es-discuss.

I've been thinking about the proposal.  I would recommend against it, main reason being that it makes the language a bit harder to read and understand at-a-glance.  

Here's why. As an example, you've listed

```const getEmail = .contacts.email;```

as a possible use case. The problem with this is that what you're essentially doing is adding a *third* way to write a function (other than "const foo = x => x" or "function foo (x) { return x }"

Now, I don't mind the arrow operator since it automatically binds "this" and makes tracking the scope of "this" easier (as well as making "this" behave more like an object-oriented programmer coming from a primarily OOP language would expect "this" to behave). Trick is, of course that in so doing, we've added a "special occasion" where if we *do* need the function to have it's own "this" scope, we need to use the longer syntax. That "=>" is shorter to type encourages it's use as the default, and when a coder looks at someone writing out "function" it warns them that something funky is about to happen with "this."

The problem with the proposal, as I see it, is that it creates a function that looks, at first glance, to be a variable assignment. Granted, that leading "." does look different from most variable assignments, but it's easy to overlook. Whether it's with an arrow function or the function keyword, when a function is defined, it is always defined with "()" somewhere in it. It is, in fact, what makes functions *look different* at a skim-level of reading comprehension, from things like assignments and operations.

By adding this new way of writing functions without () in the syntax, you increase the cognitive overhead of the programmer, which is something we want to avoid.

A concise programming language is not a programming language with the fewest characters, but the programming language with the fewest characters *necessary to make meaning clear.* I just don't think that the proposed syntax clearly indicates what it does, and violates the principle of least surprise.

So - that's my two cents as a person who isn't a language *expert* perse but does have to use ES on a daily basis.

It's still a good problem to solve, though, as (x) => x.some.property does come up quite often.  But perhaps this should be a proposal in a helper library like lodash that isn't something that all javascript programmers learning the language need to internalise. That way you could write: 

const getEmail = _.drill("contacts.email", value_if_undefined) 
or
const getEmail = _.drill(['contacts', 'email'], value_if_undefined)

get nearly the same amount of code golf, and be able to use it when you need it.  


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Selector/Select Expression

Bob Myers
Every language feature adds cognitive overhead. It is not something that can or should be avoided. It should be minimized and balanced against other factors.

Whether some codebase uses the new ```.prop``` syntax, or ```R.pick``` (from Ramda), or ```pluck("p")```. from RxJS, or some third-party or homegrown utility, the programmer will have to learn it. For such a common use case, it's better to have one thing for everyone to learn. Even then, as with most other features, people could choose not to use it, or a company could disallow its use in their styleguide if they really felt strongly enough about it.

> The problem with the proposal, as I see it, is that it creates a function that looks, at first glance, to be a variable assignment. 

I don't understand this objection. How does ```.p```, which is the notation we are talking about, look like a variable assignment? 

As mentioned earlier in the thread, if there is concern that the leading dot is easy to overlook--which I don't think is the case, and is less of a problem in any case in most editors using monospaced fonts--there are myriad alternatives, including any non-unary operator such as ```^```, some unique combination of symbols, a keyword such as `pick`, or ```?.` where the ```?``` can be read as a placeholder for an object to be passed in later. The proposal by no means rides on the specific symbol or notation chosen. The advantage of the dot is that it is the long-established notation for property access. We are merely extending that notion by assigning a different meaning when the expression on the left is omitted.



On Sun, Jun 23, 2019 at 2:31 AM Brian Boyko <[hidden email]> wrote:
Howdy. First post to es-discuss.

I've been thinking about the proposal.  I would recommend against it, main reason being that it makes the language a bit harder to read and understand at-a-glance.  

Here's why. As an example, you've listed

```const getEmail = .contacts.email;```

as a possible use case. The problem with this is that what you're essentially doing is adding a *third* way to write a function (other than "const foo = x => x" or "function foo (x) { return x }"

Now, I don't mind the arrow operator since it automatically binds "this" and makes tracking the scope of "this" easier (as well as making "this" behave more like an object-oriented programmer coming from a primarily OOP language would expect "this" to behave). Trick is, of course that in so doing, we've added a "special occasion" where if we *do* need the function to have it's own "this" scope, we need to use the longer syntax. That "=>" is shorter to type encourages it's use as the default, and when a coder looks at someone writing out "function" it warns them that something funky is about to happen with "this."

The problem with the proposal, as I see it, is that it creates a function that looks, at first glance, to be a variable assignment. Granted, that leading "." does look different from most variable assignments, but it's easy to overlook. Whether it's with an arrow function or the function keyword, when a function is defined, it is always defined with "()" somewhere in it. It is, in fact, what makes functions *look different* at a skim-level of reading comprehension, from things like assignments and operations.

By adding this new way of writing functions without () in the syntax, you increase the cognitive overhead of the programmer, which is something we want to avoid.

A concise programming language is not a programming language with the fewest characters, but the programming language with the fewest characters *necessary to make meaning clear.* I just don't think that the proposed syntax clearly indicates what it does, and violates the principle of least surprise.

So - that's my two cents as a person who isn't a language *expert* perse but does have to use ES on a daily basis.

It's still a good problem to solve, though, as (x) => x.some.property does come up quite often.  But perhaps this should be a proposal in a helper library like lodash that isn't something that all javascript programmers learning the language need to internalise. That way you could write: 

const getEmail = _.drill("contacts.email", value_if_undefined) 
or
const getEmail = _.drill(['contacts', 'email'], value_if_undefined)

get nearly the same amount of code golf, and be able to use it when you need it.  

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

Simon Farrugia
In reply to this post by Simon Farrugia

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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Selector/Select Expression

Brian Boyko
In reply to this post by Bob Myers
> Every language feature adds cognitive overhead. It is not something that can or should be avoided. It should be minimized and balanced against other factors.

True, though I'd still argue that adding a new way to generate a function without either instantiating a function (with "()") or calling a function (with "()") 

So - I get what you're saying.  

As for how ".p" looks like a variable assignment, I mean specifically that it *doesn't* look like a function assignment (which it is) and looks more like a value assignment (which it isn't.) Granted, it doesn't 100% look like *either*.  And yes, while companies can choose to not allow it in their own style guides, making it part of the language means that a user may encounter it, especially if they're trying to figure out how imported code works (not to mention, not every programmer in a company follows - or even reads - the styleguide.) 

If I *had* to have this functionality in the language (and by no means have I ever had any problem with "const foo = x => x.prop;") it would be better to define a new keyword that more explicitly explains the purpose.  

```
(window || global).propDriller = function(arrayOfProperties, defaultReturn) {
  const driller = function(parameter, arrayOfProperties, defaultReturn) {
    let working = parameter;
    if (arrayOfProperties.length === 0) {
      return working;
    }
    if (working === undefined || !(working instanceof Object)) {
      return defaultReturn;
    }
    return driller(working[arrayOfProperties[0], arrayOfProperties.slice(1), defaultReturn)
    }
  }
  return function(parameter) {
    return driller(parameter, arrayOfProperties, defaultReturn)
  }
}

const getEmail = propDriller(['user', 0, "email'], defaultReturn)

```


I'd have no objection to this whastsoever (and the above could be used as a polyfill). But again, this is something that I think is a bit of a niche use case. 

On Sun, Jun 23, 2019 at 11:01 AM Bob Myers <[hidden email]> wrote:
Every language feature adds cognitive overhead. It is not something that can or should be avoided. It should be minimized and balanced against other factors.

Whether some codebase uses the new ```.prop``` syntax, or ```R.pick``` (from Ramda), or ```pluck("p")```. from RxJS, or some third-party or homegrown utility, the programmer will have to learn it. For such a common use case, it's better to have one thing for everyone to learn. Even then, as with most other features, people could choose not to use it, or a company could disallow its use in their styleguide if they really felt strongly enough about it.

> The problem with the proposal, as I see it, is that it creates a function that looks, at first glance, to be a variable assignment. 

I don't understand this objection. How does ```.p```, which is the notation we are talking about, look like a variable assignment? 

As mentioned earlier in the thread, if there is concern that the leading dot is easy to overlook--which I don't think is the case, and is less of a problem in any case in most editors using monospaced fonts--there are myriad alternatives, including any non-unary operator such as ```^```, some unique combination of symbols, a keyword such as `pick`, or ```?.` where the ```?``` can be read as a placeholder for an object to be passed in later. The proposal by no means rides on the specific symbol or notation chosen. The advantage of the dot is that it is the long-established notation for property access. We are merely extending that notion by assigning a different meaning when the expression on the left is omitted.



On Sun, Jun 23, 2019 at 2:31 AM Brian Boyko <[hidden email]> wrote:
Howdy. First post to es-discuss.

I've been thinking about the proposal.  I would recommend against it, main reason being that it makes the language a bit harder to read and understand at-a-glance.  

Here's why. As an example, you've listed

```const getEmail = .contacts.email;```

as a possible use case. The problem with this is that what you're essentially doing is adding a *third* way to write a function (other than "const foo = x => x" or "function foo (x) { return x }"

Now, I don't mind the arrow operator since it automatically binds "this" and makes tracking the scope of "this" easier (as well as making "this" behave more like an object-oriented programmer coming from a primarily OOP language would expect "this" to behave). Trick is, of course that in so doing, we've added a "special occasion" where if we *do* need the function to have it's own "this" scope, we need to use the longer syntax. That "=>" is shorter to type encourages it's use as the default, and when a coder looks at someone writing out "function" it warns them that something funky is about to happen with "this."

The problem with the proposal, as I see it, is that it creates a function that looks, at first glance, to be a variable assignment. Granted, that leading "." does look different from most variable assignments, but it's easy to overlook. Whether it's with an arrow function or the function keyword, when a function is defined, it is always defined with "()" somewhere in it. It is, in fact, what makes functions *look different* at a skim-level of reading comprehension, from things like assignments and operations.

By adding this new way of writing functions without () in the syntax, you increase the cognitive overhead of the programmer, which is something we want to avoid.

A concise programming language is not a programming language with the fewest characters, but the programming language with the fewest characters *necessary to make meaning clear.* I just don't think that the proposed syntax clearly indicates what it does, and violates the principle of least surprise.

So - that's my two cents as a person who isn't a language *expert* perse but does have to use ES on a daily basis.

It's still a good problem to solve, though, as (x) => x.some.property does come up quite often.  But perhaps this should be a proposal in a helper library like lodash that isn't something that all javascript programmers learning the language need to internalise. That way you could write: 

const getEmail = _.drill("contacts.email", value_if_undefined) 
or
const getEmail = _.drill(['contacts', 'email'], value_if_undefined)

get nearly the same amount of code golf, and be able to use it when you need it.  

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Selector/Select Expression

Bob Myers
Minor point, but the vast majority of JS is written in corporate environments where code can't even be checked in unless it lints against the company's standard lint rules. Modern linters support an incredible variety of rules, including custom rulesets. 

I am not saying that the availability of linters (or IDEs) should drive language design decisions, or that we should assume linters or IDEs are always used or build in dependencies on them. My point is merely that they do previde a way for companies to "opt out" of features that they don't like for some reason, and thus to some extent weaken the argument that some new feature is undesirable because every single JS programmer in the world will have to learn it.


On Sun, Jun 23, 2019 at 4:00 AM Brian Boyko <[hidden email]> wrote:
> Every language feature adds cognitive overhead. It is not something that can or should be avoided. It should be minimized and balanced against other factors.

True, though I'd still argue that adding a new way to generate a function without either instantiating a function (with "()") or calling a function (with "()") 

So - I get what you're saying.  

As for how ".p" looks like a variable assignment, I mean specifically that it *doesn't* look like a function assignment (which it is) and looks more like a value assignment (which it isn't.) Granted, it doesn't 100% look like *either*.  And yes, while companies can choose to not allow it in their own style guides, making it part of the language means that a user may encounter it, especially if they're trying to figure out how imported code works (not to mention, not every programmer in a company follows - or even reads - the styleguide.) 

If I *had* to have this functionality in the language (and by no means have I ever had any problem with "const foo = x => x.prop;") it would be better to define a new keyword that more explicitly explains the purpose.  

```
(window || global).propDriller = function(arrayOfProperties, defaultReturn) {
  const driller = function(parameter, arrayOfProperties, defaultReturn) {
    let working = parameter;
    if (arrayOfProperties.length === 0) {
      return working;
    }
    if (working === undefined || !(working instanceof Object)) {
      return defaultReturn;
    }
    return driller(working[arrayOfProperties[0], arrayOfProperties.slice(1), defaultReturn)
    }
  }
  return function(parameter) {
    return driller(parameter, arrayOfProperties, defaultReturn)
  }
}

const getEmail = propDriller(['user', 0, "email'], defaultReturn)

```


I'd have no objection to this whastsoever (and the above could be used as a polyfill). But again, this is something that I think is a bit of a niche use case. 

On Sun, Jun 23, 2019 at 11:01 AM Bob Myers <[hidden email]> wrote:
Every language feature adds cognitive overhead. It is not something that can or should be avoided. It should be minimized and balanced against other factors.

Whether some codebase uses the new ```.prop``` syntax, or ```R.pick``` (from Ramda), or ```pluck("p")```. from RxJS, or some third-party or homegrown utility, the programmer will have to learn it. For such a common use case, it's better to have one thing for everyone to learn. Even then, as with most other features, people could choose not to use it, or a company could disallow its use in their styleguide if they really felt strongly enough about it.

> The problem with the proposal, as I see it, is that it creates a function that looks, at first glance, to be a variable assignment. 

I don't understand this objection. How does ```.p```, which is the notation we are talking about, look like a variable assignment? 

As mentioned earlier in the thread, if there is concern that the leading dot is easy to overlook--which I don't think is the case, and is less of a problem in any case in most editors using monospaced fonts--there are myriad alternatives, including any non-unary operator such as ```^```, some unique combination of symbols, a keyword such as `pick`, or ```?.` where the ```?``` can be read as a placeholder for an object to be passed in later. The proposal by no means rides on the specific symbol or notation chosen. The advantage of the dot is that it is the long-established notation for property access. We are merely extending that notion by assigning a different meaning when the expression on the left is omitted.



On Sun, Jun 23, 2019 at 2:31 AM Brian Boyko <[hidden email]> wrote:
Howdy. First post to es-discuss.

I've been thinking about the proposal.  I would recommend against it, main reason being that it makes the language a bit harder to read and understand at-a-glance.  

Here's why. As an example, you've listed

```const getEmail = .contacts.email;```

as a possible use case. The problem with this is that what you're essentially doing is adding a *third* way to write a function (other than "const foo = x => x" or "function foo (x) { return x }"

Now, I don't mind the arrow operator since it automatically binds "this" and makes tracking the scope of "this" easier (as well as making "this" behave more like an object-oriented programmer coming from a primarily OOP language would expect "this" to behave). Trick is, of course that in so doing, we've added a "special occasion" where if we *do* need the function to have it's own "this" scope, we need to use the longer syntax. That "=>" is shorter to type encourages it's use as the default, and when a coder looks at someone writing out "function" it warns them that something funky is about to happen with "this."

The problem with the proposal, as I see it, is that it creates a function that looks, at first glance, to be a variable assignment. Granted, that leading "." does look different from most variable assignments, but it's easy to overlook. Whether it's with an arrow function or the function keyword, when a function is defined, it is always defined with "()" somewhere in it. It is, in fact, what makes functions *look different* at a skim-level of reading comprehension, from things like assignments and operations.

By adding this new way of writing functions without () in the syntax, you increase the cognitive overhead of the programmer, which is something we want to avoid.

A concise programming language is not a programming language with the fewest characters, but the programming language with the fewest characters *necessary to make meaning clear.* I just don't think that the proposed syntax clearly indicates what it does, and violates the principle of least surprise.

So - that's my two cents as a person who isn't a language *expert* perse but does have to use ES on a daily basis.

It's still a good problem to solve, though, as (x) => x.some.property does come up quite often.  But perhaps this should be a proposal in a helper library like lodash that isn't something that all javascript programmers learning the language need to internalise. That way you could write: 

const getEmail = _.drill("contacts.email", value_if_undefined) 
or
const getEmail = _.drill(['contacts', 'email'], value_if_undefined)

get nearly the same amount of code golf, and be able to use it when you need it.  

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Selector/Select Expression

Brian Boyko
I suppose what I'm making is a subjective argument, because there's no way to precisely measure "cognitive load" or "utility," just certain rules of thumb and guidelines passed down over the generations. 

I suppose what it boils down to, is that I (subjectively) think that there's a very high price being paid for a (subjectively) low use case, when the existing syntax can be used without many more characters typed to solve the problem the new syntax is trying to solve. 

On Sun, Jun 23, 2019 at 10:03 PM Bob Myers <[hidden email]> wrote:
Minor point, but the vast majority of JS is written in corporate environments where code can't even be checked in unless it lints against the company's standard lint rules. Modern linters support an incredible variety of rules, including custom rulesets. 

I am not saying that the availability of linters (or IDEs) should drive language design decisions, or that we should assume linters or IDEs are always used or build in dependencies on them. My point is merely that they do previde a way for companies to "opt out" of features that they don't like for some reason, and thus to some extent weaken the argument that some new feature is undesirable because every single JS programmer in the world will have to learn it.


On Sun, Jun 23, 2019 at 4:00 AM Brian Boyko <[hidden email]> wrote:
> Every language feature adds cognitive overhead. It is not something that can or should be avoided. It should be minimized and balanced against other factors.

True, though I'd still argue that adding a new way to generate a function without either instantiating a function (with "()") or calling a function (with "()") 

So - I get what you're saying.  

As for how ".p" looks like a variable assignment, I mean specifically that it *doesn't* look like a function assignment (which it is) and looks more like a value assignment (which it isn't.) Granted, it doesn't 100% look like *either*.  And yes, while companies can choose to not allow it in their own style guides, making it part of the language means that a user may encounter it, especially if they're trying to figure out how imported code works (not to mention, not every programmer in a company follows - or even reads - the styleguide.) 

If I *had* to have this functionality in the language (and by no means have I ever had any problem with "const foo = x => x.prop;") it would be better to define a new keyword that more explicitly explains the purpose.  

```
(window || global).propDriller = function(arrayOfProperties, defaultReturn) {
  const driller = function(parameter, arrayOfProperties, defaultReturn) {
    let working = parameter;
    if (arrayOfProperties.length === 0) {
      return working;
    }
    if (working === undefined || !(working instanceof Object)) {
      return defaultReturn;
    }
    return driller(working[arrayOfProperties[0], arrayOfProperties.slice(1), defaultReturn)
    }
  }
  return function(parameter) {
    return driller(parameter, arrayOfProperties, defaultReturn)
  }
}

const getEmail = propDriller(['user', 0, "email'], defaultReturn)

```


I'd have no objection to this whastsoever (and the above could be used as a polyfill). But again, this is something that I think is a bit of a niche use case. 

On Sun, Jun 23, 2019 at 11:01 AM Bob Myers <[hidden email]> wrote:
Every language feature adds cognitive overhead. It is not something that can or should be avoided. It should be minimized and balanced against other factors.

Whether some codebase uses the new ```.prop``` syntax, or ```R.pick``` (from Ramda), or ```pluck("p")```. from RxJS, or some third-party or homegrown utility, the programmer will have to learn it. For such a common use case, it's better to have one thing for everyone to learn. Even then, as with most other features, people could choose not to use it, or a company could disallow its use in their styleguide if they really felt strongly enough about it.

> The problem with the proposal, as I see it, is that it creates a function that looks, at first glance, to be a variable assignment. 

I don't understand this objection. How does ```.p```, which is the notation we are talking about, look like a variable assignment? 

As mentioned earlier in the thread, if there is concern that the leading dot is easy to overlook--which I don't think is the case, and is less of a problem in any case in most editors using monospaced fonts--there are myriad alternatives, including any non-unary operator such as ```^```, some unique combination of symbols, a keyword such as `pick`, or ```?.` where the ```?``` can be read as a placeholder for an object to be passed in later. The proposal by no means rides on the specific symbol or notation chosen. The advantage of the dot is that it is the long-established notation for property access. We are merely extending that notion by assigning a different meaning when the expression on the left is omitted.



On Sun, Jun 23, 2019 at 2:31 AM Brian Boyko <[hidden email]> wrote:
Howdy. First post to es-discuss.

I've been thinking about the proposal.  I would recommend against it, main reason being that it makes the language a bit harder to read and understand at-a-glance.  

Here's why. As an example, you've listed

```const getEmail = .contacts.email;```

as a possible use case. The problem with this is that what you're essentially doing is adding a *third* way to write a function (other than "const foo = x => x" or "function foo (x) { return x }"

Now, I don't mind the arrow operator since it automatically binds "this" and makes tracking the scope of "this" easier (as well as making "this" behave more like an object-oriented programmer coming from a primarily OOP language would expect "this" to behave). Trick is, of course that in so doing, we've added a "special occasion" where if we *do* need the function to have it's own "this" scope, we need to use the longer syntax. That "=>" is shorter to type encourages it's use as the default, and when a coder looks at someone writing out "function" it warns them that something funky is about to happen with "this."

The problem with the proposal, as I see it, is that it creates a function that looks, at first glance, to be a variable assignment. Granted, that leading "." does look different from most variable assignments, but it's easy to overlook. Whether it's with an arrow function or the function keyword, when a function is defined, it is always defined with "()" somewhere in it. It is, in fact, what makes functions *look different* at a skim-level of reading comprehension, from things like assignments and operations.

By adding this new way of writing functions without () in the syntax, you increase the cognitive overhead of the programmer, which is something we want to avoid.

A concise programming language is not a programming language with the fewest characters, but the programming language with the fewest characters *necessary to make meaning clear.* I just don't think that the proposed syntax clearly indicates what it does, and violates the principle of least surprise.

So - that's my two cents as a person who isn't a language *expert* perse but does have to use ES on a daily basis.

It's still a good problem to solve, though, as (x) => x.some.property does come up quite often.  But perhaps this should be a proposal in a helper library like lodash that isn't something that all javascript programmers learning the language need to internalise. That way you could write: 

const getEmail = _.drill("contacts.email", value_if_undefined) 
or
const getEmail = _.drill(['contacts', 'email'], value_if_undefined)

get nearly the same amount of code golf, and be able to use it when you need it.  

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

Michael Luder-Rosefield
In reply to this post by Simon Farrugia
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, <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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, <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Selector/Select Expression

Simon Farrugia
In reply to this post by 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Selector/Select Expression

Simon Farrugia
In reply to this post by 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

Isiah Meadows-2
In reply to this post by Michael Luder-Rosefield
Generalize this far enough, and you wind up with something not far
from this: https://github.com/tc39/proposal-partial-application

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Wed, Jun 26, 2019 at 5:44 AM Michael Luder-Rosefield
<[hidden email]> 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, <[hidden email]> 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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Re: Proposal: Selector/Select Expression

Simon Farrugia

Also, without a leading token, a selector expr with the optional chaining operator inside a ternary operator would be ambiguous.

```

const contactSelector = true ? .contacts.email : .contacts.phone;

```

 

From: [hidden email]
Sent: 27 June 2019 19:18
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: Re: Proposal: Selector/Select Expression

 

Generalize this far enough, and you wind up with something not far

from this: https://github.com/tc39/proposal-partial-application

 

-----

 

Isiah Meadows

[hidden email]

www.isiahmeadows.com

 

On Wed, Jun 26, 2019 at 5:44 AM Michael Luder-Rosefield

<[hidden email]> 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, <[hidden email]> 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

>> [hidden email]

>> https://mail.mozilla.org/listinfo/es-discuss

> 

> _______________________________________________

> es-discuss mailing list

> [hidden email]

> https://mail.mozilla.org/listinfo/es-discuss

 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

Bob Myers
Not exactly, since the optional chaining operator is `?.` with no space in between.

On Thu, Jun 27, 2019 at 1:37 PM Simon Farrugia <[hidden email]> wrote:

Also, without a leading token, a selector expr with the optional chaining operator inside a ternary operator would be ambiguous.

```

const contactSelector = true ? .contacts.email : .contacts.phone;

```



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

guest271314
The space character/no space character would probably only be a limiting factor for golf. The differennces should be clearly explained (at each proposal, eventual specification) for disambiguation nonetheless.

On Thu, Jun 27, 2019 at 8:48 PM Bob Myers <[hidden email]> wrote:
Not exactly, since the optional chaining operator is `?.` with no space in between.

On Thu, Jun 27, 2019 at 1:37 PM Simon Farrugia <[hidden email]> wrote:

Also, without a leading token, a selector expr with the optional chaining operator inside a ternary operator would be ambiguous.

```

const contactSelector = true ? .contacts.email : .contacts.phone;

```


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

guest271314
In reply to this post by Bob Myers
How can the Selector/Select Expression be used with `Array.prototype.find()`? What happens when the property is not defined?

For example using the same code for more than one browser

```
const stream = [canvasStream, videoTrack].find(({requestFrame: _}) => _);
```

the property `requestFrame` is either defined or not defined at ```canvasStream``` or ```videoTrack``` depending on the implementation. Although the assigned variable can be reduced to 1 character at destructuring assignment, there is still the redundancy of writing ```_``` again on the right side of ```=>```.

If the property is not found, is the result ```undefined```?

What is the least amount characters necessary using Selector/Select Expression with ```find()```?

```
const stream = [canvasStream, videoTrack].find(=.requestFrame);
```

?

On Thu, Jun 27, 2019 at 8:48 PM Bob Myers <[hidden email]> wrote:
Not exactly, since the optional chaining operator is `?.` with no space in between.

On Thu, Jun 27, 2019 at 1:37 PM Simon Farrugia <[hidden email]> wrote:

Also, without a leading token, a selector expr with the optional chaining operator inside a ternary operator would be ambiguous.

```

const contactSelector = true ? .contacts.email : .contacts.phone;

```


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

Bob Myers
If the intent is to find the first entry with a truthy value for the `requestFrame` property, then the proposal is `array.find(.requestFrame)`.
If the "wildcard" syntax is used, then it would be `array.find(?.requestFrame)`.

On Thu, Jun 27, 2019 at 5:30 PM guest271314 <[hidden email]> wrote:
How can the Selector/Select Expression be used with `Array.prototype.find()`? What happens when the property is not defined?

For example using the same code for more than one browser

```
const stream = [canvasStream, videoTrack].find(({requestFrame: _}) => _);
```

the property `requestFrame` is either defined or not defined at ```canvasStream``` or ```videoTrack``` depending on the implementation. Although the assigned variable can be reduced to 1 character at destructuring assignment, there is still the redundancy of writing ```_``` again on the right side of ```=>```.

If the property is not found, is the result ```undefined```?

Since `.prop` is defined to be identically semantically to `o => o.prop`, yes, the function `.prop` applied to an object with no property named `prop` returns `undefined`. 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

guest271314

> then the proposal is `array.find(.requestFrame)`.
>
> Since `.prop` is defined to be identically semantically to `o => o.prop`, yes, the function `.prop` applied to an object with no property named `prop` returns `undefined`.

Has the opposite, ```!``` and ```!!``` preceding ```.prop```, ```const d = [a, b].find(!.c);``` or  ```const d = [a, b].find(!(.c));```  been considered? 

And ```async``` functions ```const d = [a, b].find(async (await(.c)));```?


On Fri, Jun 28, 2019 at 12:48 AM Bob Myers <[hidden email]> wrote:
If the intent is to find the first entry with a truthy value for the `requestFrame` property, then the proposal is `array.find(.requestFrame)`.
If the "wildcard" syntax is used, then it would be `array.find(?.requestFrame)`.

On Thu, Jun 27, 2019 at 5:30 PM guest271314 <[hidden email]> wrote:
How can the Selector/Select Expression be used with `Array.prototype.find()`? What happens when the property is not defined?

For example using the same code for more than one browser

```
const stream = [canvasStream, videoTrack].find(({requestFrame: _}) => _);
```

the property `requestFrame` is either defined or not defined at ```canvasStream``` or ```videoTrack``` depending on the implementation. Although the assigned variable can be reduced to 1 character at destructuring assignment, there is still the redundancy of writing ```_``` again on the right side of ```=>```.

If the property is not found, is the result ```undefined```?

Since `.prop` is defined to be identically semantically to `o => o.prop`, yes, the function `.prop` applied to an object with no property named `prop` returns `undefined`. 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

Isiah Meadows-2
In reply to this post by Bob Myers
Agreed in that it's not ambiguous - you have to disambiguate it with a space for the same reason you have to use `a+ +b` instead of `a++b` in minified code to avoid ambiguity when specifying `a + +b`. So `a?.b:.c` would be invalid, but `a? .b:.c` is not.

On Thu, Jun 27, 2019 at 16:48 Bob Myers <[hidden email]> wrote:
Not exactly, since the optional chaining operator is `?.` with no space in between.

On Thu, Jun 27, 2019 at 1:37 PM Simon Farrugia <[hidden email]> wrote:

Also, without a leading token, a selector expr with the optional chaining operator inside a ternary operator would be ambiguous.

```

const contactSelector = true ? .contacts.email : .contacts.phone;

```


--

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

Isiah Meadows-2
In reply to this post by guest271314
If missing, the expectation is that it's return `undefined` just like how `a.foo` returns `undefined` if `a` has no property `"foo"`. It's just shorthand for `x => x.foo` and similar.

On Thu, Jun 27, 2019 at 20:30 guest271314 <[hidden email]> wrote:
How can the Selector/Select Expression be used with `Array.prototype.find()`? What happens when the property is not defined?

For example using the same code for more than one browser

```
const stream = [canvasStream, videoTrack].find(({requestFrame: _}) => _);
```

the property `requestFrame` is either defined or not defined at ```canvasStream``` or ```videoTrack``` depending on the implementation. Although the assigned variable can be reduced to 1 character at destructuring assignment, there is still the redundancy of writing ```_``` again on the right side of ```=>```.

If the property is not found, is the result ```undefined```?

What is the least amount characters necessary using Selector/Select Expression with ```find()```?

```
const stream = [canvasStream, videoTrack].find(=.requestFrame);
```

?

On Thu, Jun 27, 2019 at 8:48 PM Bob Myers <[hidden email]> wrote:
Not exactly, since the optional chaining operator is `?.` with no space in between.

On Thu, Jun 27, 2019 at 1:37 PM Simon Farrugia <[hidden email]> wrote:

Also, without a leading token, a selector expr with the optional chaining operator inside a ternary operator would be ambiguous.

```

const contactSelector = true ? .contacts.email : .contacts.phone;

```


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
--

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Selector/Select Expression

Isiah Meadows-2
In reply to this post by Isiah Meadows-2
Note: the wildcard syntax `?.foo` would itself not require this. It'd require a space after the `?` in ternaries if the Elvis operator proposal `a ?? b` comes along (and a grammatical edit isn't made to clarify `??.` gets parsed as `? ?.`), but it would not otherwise be ambiguous.

On Fri, Jun 28, 2019 at 11:25 Isiah Meadows <[hidden email]> wrote:
Agreed in that it's not ambiguous - you have to disambiguate it with a space for the same reason you have to use `a+ +b` instead of `a++b` in minified code to avoid ambiguity when specifying `a + +b`. So `a?.b:.c` would be invalid, but `a? .b:.c` is not.

On Thu, Jun 27, 2019 at 16:48 Bob Myers <[hidden email]> wrote:
Not exactly, since the optional chaining operator is `?.` with no space in between.

On Thu, Jun 27, 2019 at 1:37 PM Simon Farrugia <[hidden email]> wrote:

Also, without a leading token, a selector expr with the optional chaining operator inside a ternary operator would be ambiguous.

```

const contactSelector = true ? .contacts.email : .contacts.phone;

```


--
--

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12