Proposal: Selector/Select Expression

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

Proposal: Selector/Select Expression

Simon Farrugia

Selector/Select Expression 

 

Doing functional & reactive programming is currently really verbose in JavaScript.  

Hopefully this issue will be alleviated with the addition of the pipe operator in the near future. 

 

One things you end up doing most when doing fp is doing simple selections (mappings) on objects & arrays. This unfortunately becomes really verbose and repetitive. 

 

What I'm proposing is to be able to collapse/simplify selector arrow function expressions like this: 

 

``` 

// user => email 

const getEmail = user => user.contacts.email; 

``` 

 

to something like this: 

 

``` 

// user => email 

const getEmail = .contacts.email; 

``` 

 

More examples: 

 

``` 

// user[] => email[] (With Arrays) 

const getEmailsList = users => users.map(user => user.contacts.email); 

const getEmailsList = .map(.contacts.email); 

``` 

 

``` 

// Usage with pipeline operator 

pipe(user, map(user => user.contacts.email)) 

user |> .contacts.email 

``` 

 

I think this would work really well, particularly in conjunction with the pipeline operator, resulting in more concise and expressive code improving readability. 

This is just syntactic sugar, but same as in the case of the pipeline operator, selector functions are so intrinsic and commonplace to any code base, that I would think it's worth considering. 

 

I would  appreciate hearing your thoughts. Thanks. 


_______________________________________________
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

Scott Rudiger
I can appreciate the intent of the proposal. 👍

Minor nit with one of the examples:

// user[] => email[] (With Arrays) 

const getEmailsList = users => users.map(user => user.contacts.email); 

const getEmailsList = .map(.contacts.email); 

```


I would think with the proposal you'd still need to reference `users`. Otherwise what are we mapping?


```

const getEmailsList = users.map(.contacts.email); 

```


On Fri, Jun 21, 2019, 4:49 AM Simon Farrugia <[hidden email]> wrote:

Selector/Select Expression 

 

Doing functional & reactive programming is currently really verbose in JavaScript.  

Hopefully this issue will be alleviated with the addition of the pipe operator in the near future. 

 

One things you end up doing most when doing fp is doing simple selections (mappings) on objects & arrays. This unfortunately becomes really verbose and repetitive. 

 

What I'm proposing is to be able to collapse/simplify selector arrow function expressions like this: 

 

``` 

// user => email 

const getEmail = user => user.contacts.email; 

``` 

 

to something like this: 

 

``` 

// user => email 

const getEmail = .contacts.email; 

``` 

 

More examples: 

 

``` 

// user[] => email[] (With Arrays) 

const getEmailsList = users => users.map(user => user.contacts.email); 

const getEmailsList = .map(.contacts.email); 

```

 

``` 

// Usage with pipeline operator 

pipe(user, map(user => user.contacts.email)) 

user |> .contacts.email 

``` 

 

I think this would work really well, particularly in conjunction with the pipeline operator, resulting in more concise and expressive code improving readability. 

This is just syntactic sugar, but same as in the case of the pipeline operator, selector functions are so intrinsic and commonplace to any code base, that I would think it's worth considering. 

 

I would  appreciate hearing your thoughts. Thanks. 

_______________________________________________
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

Adam Eisenreich
This new notation will enable you a new way to create functions

`.map(...)` produces `(parameter) => parameter.map(...)`, it is not evaluated, it is a function definition

I cannot say I like it. To me it is less readable, confusing to be exact. Anything leading with `.` (dot), seems unusual



I can appreciate the intent of the proposal. 👍

Minor nit with one of the examples:

// user[] => email[] (With Arrays) 

const getEmailsList = users => users.map(user => user.contacts.email); 

const getEmailsList = .map(.contacts.email); 

```


I would think with the proposal you'd still need to reference `users`. Otherwise what are we mapping?


```

const getEmailsList = users.map(.contacts.email); 

```


On Fri, Jun 21, 2019, 4:49 AM Simon Farrugia <[hidden email]> wrote:

Selector/Select Expression 

 

Doing functional & reactive programming is currently really verbose in JavaScript.  

Hopefully this issue will be alleviated with the addition of the pipe operator in the near future. 

 

One things you end up doing most when doing fp is doing simple selections (mappings) on objects & arrays. This unfortunately becomes really verbose and repetitive. 

 

What I'm proposing is to be able to collapse/simplify selector arrow function expressions like this: 

 

``` 

// user => email 

const getEmail = user => user.contacts.email; 

``` 

 

to something like this: 

 

``` 

// user => email 

const getEmail = .contacts.email; 

``` 

 

More examples: 

 

``` 

// user[] => email[] (With Arrays) 

const getEmailsList = users => users.map(user => user.contacts.email); 

const getEmailsList = .map(.contacts.email); 

```

 

``` 

// Usage with pipeline operator 

pipe(user, map(user => user.contacts.email)) 

user |> .contacts.email 

``` 

 

I think this would work really well, particularly in conjunction with the pipeline operator, resulting in more concise and expressive code improving readability. 

This is just syntactic sugar, but same as in the case of the pipeline operator, selector functions are so intrinsic and commonplace to any code base, that I would think it's worth considering. 

 

I would  appreciate hearing your thoughts. Thanks. 

_______________________________________________
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 Scott Rudiger
Thanks for the feedback Scott,

Regarding your concern about the array example, both expressions are valid but different:

This (what you wrote) would map the array of users to an array of emails and declare getEmailsList as an array of emails.
```
const getEmailsList = users.map(.contacts.email);
```

While this (my array example) would define getEmailsList as a function that takes an array of users and returns an array of emails.
```
const getEmailsList = .map(.contacts.email);

On Fri, Jun 21, 2019 at 3:27 PM Scott Rudiger <[hidden email]> wrote:
I can appreciate the intent of the proposal. 👍

Minor nit with one of the examples:

// user[] => email[] (With Arrays) 

const getEmailsList = users => users.map(user => user.contacts.email); 

const getEmailsList = .map(.contacts.email); 

```


I would think with the proposal you'd still need to reference `users`. Otherwise what are we mapping?


```

const getEmailsList = users.map(.contacts.email); 

```


On Fri, Jun 21, 2019, 4:49 AM Simon Farrugia <[hidden email]> wrote:

Selector/Select Expression 

 

Doing functional & reactive programming is currently really verbose in JavaScript.  

Hopefully this issue will be alleviated with the addition of the pipe operator in the near future. 

 

One things you end up doing most when doing fp is doing simple selections (mappings) on objects & arrays. This unfortunately becomes really verbose and repetitive. 

 

What I'm proposing is to be able to collapse/simplify selector arrow function expressions like this: 

 

``` 

// user => email 

const getEmail = user => user.contacts.email; 

``` 

 

to something like this: 

 

``` 

// user => email 

const getEmail = .contacts.email; 

``` 

 

More examples: 

 

``` 

// user[] => email[] (With Arrays) 

const getEmailsList = users => users.map(user => user.contacts.email); 

const getEmailsList = .map(.contacts.email); 

```

 

``` 

// Usage with pipeline operator 

pipe(user, map(user => user.contacts.email)) 

user |> .contacts.email 

``` 

 

I think this would work really well, particularly in conjunction with the pipeline operator, resulting in more concise and expressive code improving readability. 

This is just syntactic sugar, but same as in the case of the pipeline operator, selector functions are so intrinsic and commonplace to any code base, that I would think it's worth considering. 

 

I would  appreciate hearing your thoughts. Thanks. 

_______________________________________________
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

Scott Rudiger
Got it, that make sense.

I like the motivation behind the proposal. If it moves forward, I could see people possibly not liking (and bikeshedding) on the bare dot syntax, especially as it adds a new form of defining a function. Although, personally, I got used to it in less than a minute.

On Fri, Jun 21, 2019 at 7:02 AM Simon Farrugia <[hidden email]> wrote:
Thanks for the feedback Scott,

Regarding your concern about the array example, both expressions are valid but different:

This (what you wrote) would map the array of users to an array of emails and declare getEmailsList as an array of emails.
```
const getEmailsList = users.map(.contacts.email);
```

While this (my array example) would define getEmailsList as a function that takes an array of users and returns an array of emails.
```
const getEmailsList = .map(.contacts.email);

On Fri, Jun 21, 2019 at 3:27 PM Scott Rudiger <[hidden email]> wrote:
I can appreciate the intent of the proposal. 👍

Minor nit with one of the examples:

// user[] => email[] (With Arrays) 

const getEmailsList = users => users.map(user => user.contacts.email); 

const getEmailsList = .map(.contacts.email); 

```


I would think with the proposal you'd still need to reference `users`. Otherwise what are we mapping?


```

const getEmailsList = users.map(.contacts.email); 

```


On Fri, Jun 21, 2019, 4:49 AM Simon Farrugia <[hidden email]> wrote:

Selector/Select Expression 

 

Doing functional & reactive programming is currently really verbose in JavaScript.  

Hopefully this issue will be alleviated with the addition of the pipe operator in the near future. 

 

One things you end up doing most when doing fp is doing simple selections (mappings) on objects & arrays. This unfortunately becomes really verbose and repetitive. 

 

What I'm proposing is to be able to collapse/simplify selector arrow function expressions like this: 

 

``` 

// user => email 

const getEmail = user => user.contacts.email; 

``` 

 

to something like this: 

 

``` 

// user => email 

const getEmail = .contacts.email; 

``` 

 

More examples: 

 

``` 

// user[] => email[] (With Arrays) 

const getEmailsList = users => users.map(user => user.contacts.email); 

const getEmailsList = .map(.contacts.email); 

```

 

``` 

// Usage with pipeline operator 

pipe(user, map(user => user.contacts.email)) 

user |> .contacts.email 

``` 

 

I think this would work really well, particularly in conjunction with the pipeline operator, resulting in more concise and expressive code improving readability. 

This is just syntactic sugar, but same as in the case of the pipeline operator, selector functions are so intrinsic and commonplace to any code base, that I would think it's worth considering. 

 

I would  appreciate hearing your thoughts. Thanks. 

_______________________________________________
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
New syntax will always look a bit odd at first until we get used to it.

I sometimes find nested arrow functions a bit confusing to understand where one function starts and where it ends particularly when they are one liners.
This syntax is more concise and personally I find it more readable.

Reasons for the leading dot notation is because I think it's intuitive and also self explanatory:
1) We just remove what is in common on both ends of the expression (like simplifying an algebraic expression).
```
const getEmail = user => user.contacts.email;
```
2) The leading dot indicates that the expression reads the property of an object that is not statically defined.
```
const getEmail = .contacts.email;
```

_______________________________________________
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
Personally, I'm a huge fan of this proposal. It would integrate into the language the extremely frequent idiom of defining a pick/pluck like function. There is ample prior art in the form of Ramda's pick function.as well as `pluck` in RxJS.

In fact, this exact proposal was at one point included in the proposal for "extended dot notation", then removed in the interests of making making it more digestible.

AFAICS the syntax is completely unambigious:

```
const pickName = .name; // equivalent to ({name}) => name
[{id: 1, name: "Bob"}, {id: 2, name: "Sally"}].map(pickName
```

The only objection I can think of is that the leading dot is sometimes hard to see. I would have suggested using the hash mark--in fact, an early version of the exptended dot notation proposal did propose that--but now that has been taken by the private fields proposal, so unless we want to go in the direction of keywords or magic operator sequences we are reduced to using non-unary operators such as ^, so

```
const pickName = ^name;
```


On Fri, Jun 21, 2019 at 9:47 AM Simon Farrugia <[hidden email]> wrote:
New syntax will always look a bit odd at first until we get used to it.

I sometimes find nested arrow functions a bit confusing to understand where one function starts and where it ends particularly when they are one liners.
This syntax is more concise and personally I find it more readable.

Reasons for the leading dot notation is because I think it's intuitive and also self explanatory:
1) We just remove what is in common on both ends of the expression (like simplifying an algebraic expression).
```
const getEmail = user => user.contacts.email;
```
2) The leading dot indicates that the expression reads the property of an object that is not statically defined.
```
const getEmail = .contacts.email;
```
_______________________________________________
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

Barret Furton
I wonder if this could be accomplished with a proxy object instead of new syntax.

```js
const o = new Proxy(/* some implementation */);

const pickName = o.name;

pickName({ name: "Bob" }); // "Bob"

// maybe this could work too with a recursive proxy
// with handlers for access and invocation
const safePickBaz = o.foo.bar.baz;

safePickBaz({ foo: 20 }) // undefined
```

On Fri, Jun 21, 2019 at 7:55 PM Bob Myers <[hidden email]> wrote:
Personally, I'm a huge fan of this proposal. It would integrate into the language the extremely frequent idiom of defining a pick/pluck like function. There is ample prior art in the form of Ramda's pick function.as well as `pluck` in RxJS.

In fact, this exact proposal was at one point included in the proposal for "extended dot notation", then removed in the interests of making making it more digestible.

AFAICS the syntax is completely unambigious:

```
const pickName = .name; // equivalent to ({name}) => name
[{id: 1, name: "Bob"}, {id: 2, name: "Sally"}].map(pickName
```

The only objection I can think of is that the leading dot is sometimes hard to see. I would have suggested using the hash mark--in fact, an early version of the exptended dot notation proposal did propose that--but now that has been taken by the private fields proposal, so unless we want to go in the direction of keywords or magic operator sequences we are reduced to using non-unary operators such as ^, so

```
const pickName = ^name;
```


On Fri, Jun 21, 2019 at 9:47 AM Simon Farrugia <[hidden email]> wrote:
New syntax will always look a bit odd at first until we get used to it.

I sometimes find nested arrow functions a bit confusing to understand where one function starts and where it ends particularly when they are one liners.
This syntax is more concise and personally I find it more readable.

Reasons for the leading dot notation is because I think it's intuitive and also self explanatory:
1) We just remove what is in common on both ends of the expression (like simplifying an algebraic expression).
```
const getEmail = user => user.contacts.email;
```
2) The leading dot indicates that the expression reads the property of an object that is not statically defined.
```
const getEmail = .contacts.email;
```
_______________________________________________
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

guest271314
In reply to this post by Simon Farrugia
Does not destructuring assignment provide a means to achieve the requirement?

```const getEmail = ({contacts:{email:_}}) => _;```

```const getEmailsList = users.map(getEmail);```

```const {contacts:{email:getEmail}} = user;```

On Fri, Jun 21, 2019 at 11:49 AM Simon Farrugia <[hidden email]> wrote:

Selector/Select Expression 

 

Doing functional & reactive programming is currently really verbose in JavaScript.  

Hopefully this issue will be alleviated with the addition of the pipe operator in the near future. 

 

One things you end up doing most when doing fp is doing simple selections (mappings) on objects & arrays. This unfortunately becomes really verbose and repetitive. 

 

What I'm proposing is to be able to collapse/simplify selector arrow function expressions like this: 

 

``` 

// user => email 

const getEmail = user => user.contacts.email; 

``` 

 

to something like this: 

 

``` 

// user => email 

const getEmail = .contacts.email; 

``` 

 

More examples: 

 

``` 

// user[] => email[] (With Arrays) 

const getEmailsList = users => users.map(user => user.contacts.email); 

const getEmailsList = .map(.contacts.email); 

``` 

 

``` 

// Usage with pipeline operator 

pipe(user, map(user => user.contacts.email)) 

user |> .contacts.email 

``` 

 

I think this would work really well, particularly in conjunction with the pipeline operator, resulting in more concise and expressive code improving readability. 

This is just syntactic sugar, but same as in the case of the pipeline operator, selector functions are so intrinsic and commonplace to any code base, that I would think it's worth considering. 

 

I would  appreciate hearing your thoughts. Thanks. 

_______________________________________________
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
On Sat, Jun 22, 2019 at 10:59 AM guest271314 <[hidden email]> wrote:
Does not destructuring assignment provide a means to achieve the requirement?

If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.

_______________________________________________
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

guest271314
> If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.

The term "readable" is entirely subjective. As far as am aware there is no standard for "readable" (in any language, coding or not). Even if such criteria for "readable" did exist in some institutional document, no author of code (or anything else) is bound to recognize or adhere to any such subjective and arbitrary criteria. 

What specific definition of "reliable" is being used, and what are the cases that demonstrates using destructing assignment is not "reliable"? 

On Sat, Jun 22, 2019 at 6:50 PM Bob Myers <[hidden email]> wrote:
On Sat, Jun 22, 2019 at 10:59 AM guest271314 <[hidden email]> wrote:
Does not destructuring assignment provide a means to achieve the requirement?

If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.

_______________________________________________
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

Using a recursive Proxy to achieve this is a really smart @Barret.

 

Having said that, a recursive proxy implementation would surely not be possible without taking a significant performance hit.

Thus, I don’t think Proxies are ideal for anything that is meant to be widely used throughout the codebase.

 

Also, something else that I think we should keep in mind since type systems like TypeScript have been widely adopted is how such type systems would be able to infer the type from a recursive Proxy.


_______________________________________________
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
In reply to this post by guest271314
The world is awash in subjectivity. 

We can nevertheless hope to find broad agreement on at least a transitive ranking of attributes such as readability; if we don't think we can, then we are epistemological nihilists with no criteria whatsoever on which to base our language design decisions and this mailing list would have no raison d'etre, since we would never be able to align on anything.

However subjective the notion of readability, I think few would disagree that the first fragment below is more readable than the second.

```
.name
```

and

```
({name}) => name
```

The first is also more reliable by most measures, because it removes the possibility of misspelling one of the instances of ```name``` in the second, which we would prefer not to rely entirely opn type checkers or linters to pick up.

Yes, to read the first does require additional knowledge, namely of the fact that the syntax ```<dot>property``` denotes a function to retrieve the value of the property by that name. But this is no more a readability problem than the fact that one must have knowledge of the English worrds in a sentence in order for them to be "readable". Such knowledge is often referred to by terms such as "cognitive footprint". Yes, this proposal does have a cognitive footprint. But all language features have cognitive footprints, requiring that people writing and reading code using the feature have knowledge of the feature. The issue then becomes the *size* of the cognitive footprint in relation to the benefit--an equation both sides of which involve subjectivity...

Of course, I did not mean to imply that readability or reliability in and ot themselves are either necessary or sufficient for a new languge feature, There are many other aspects, as many as a dozen, which have been discussed and defined in earlier threads.

Bob

On Sat, Jun 22, 2019 at 12:08 PM guest271314 <[hidden email]> wrote:
> If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.

The term "readable" is entirely subjective. As far as am aware there is no standard for "readable" (in any language, coding or not). Even if such criteria for "readable" did exist in some institutional document, no author of code (or anything else) is bound to recognize or adhere to any such subjective and arbitrary criteria. 

What specific definition of "reliable" is being used, and what are the cases that demonstrates using destructing assignment is not "reliable"? 

On Sat, Jun 22, 2019 at 6:50 PM Bob Myers <[hidden email]> wrote:
On Sat, Jun 22, 2019 at 10:59 AM guest271314 <[hidden email]> wrote:
Does not destructuring assignment provide a means to achieve the requirement?

If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.

_______________________________________________
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

Gus Caplan
When we're dealing with code this small, I don't think readability is as important of an element. Personally I would do `((a) => a.name)`, which is short and, most importantly, very explicit about what it is doing. If you know what a function is and you know what a property is, you know what this code does. Adding additional syntax to a language requires increasingly esoteric knowledge of said language.

On Sat, Jun 22, 2019 at 7:13 PM Bob Myers <[hidden email]> wrote:
The world is awash in subjectivity. 

We can nevertheless hope to find broad agreement on at least a transitive ranking of attributes such as readability; if we don't think we can, then we are epistemological nihilists with no criteria whatsoever on which to base our language design decisions and this mailing list would have no raison d'etre, since we would never be able to align on anything.

However subjective the notion of readability, I think few would disagree that the first fragment below is more readable than the second.

```
.name
```

and

```
({name}) => name
```

The first is also more reliable by most measures, because it removes the possibility of misspelling one of the instances of ```name``` in the second, which we would prefer not to rely entirely opn type checkers or linters to pick up.

Yes, to read the first does require additional knowledge, namely of the fact that the syntax ```<dot>property``` denotes a function to retrieve the value of the property by that name. But this is no more a readability problem than the fact that one must have knowledge of the English worrds in a sentence in order for them to be "readable". Such knowledge is often referred to by terms such as "cognitive footprint". Yes, this proposal does have a cognitive footprint. But all language features have cognitive footprints, requiring that people writing and reading code using the feature have knowledge of the feature. The issue then becomes the *size* of the cognitive footprint in relation to the benefit--an equation both sides of which involve subjectivity...

Of course, I did not mean to imply that readability or reliability in and ot themselves are either necessary or sufficient for a new languge feature, There are many other aspects, as many as a dozen, which have been discussed and defined in earlier threads.

Bob

On Sat, Jun 22, 2019 at 12:08 PM guest271314 <[hidden email]> wrote:
> If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.

The term "readable" is entirely subjective. As far as am aware there is no standard for "readable" (in any language, coding or not). Even if such criteria for "readable" did exist in some institutional document, no author of code (or anything else) is bound to recognize or adhere to any such subjective and arbitrary criteria. 

What specific definition of "reliable" is being used, and what are the cases that demonstrates using destructing assignment is not "reliable"? 

On Sat, Jun 22, 2019 at 6:50 PM Bob Myers <[hidden email]> wrote:
On Sat, Jun 22, 2019 at 10:59 AM guest271314 <[hidden email]> wrote:
Does not destructuring assignment provide a means to achieve the requirement?

If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.
_______________________________________________
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

guest271314
In reply to this post by Bob Myers
then we are epistemological nihilists with no criteria whatsoever on which to base our language design decisions and this mailing list would have no raison d'etre, since we would never be able to align on anything.

That can be the case. Agreement is not required by the parties for a specification or any other document to be drafted, published, and even enforced. Even a treaty between nation-states. The populace can absolutely disagree with the authors of the document. One or more parties can sign but ignore some or all sections of one or all treaties between sovereigns.

But this is no more a readability problem than the fact that one must have knowledge of the English worrds in a sentence in order for them to be "readable".

That is indeed accurate. The engish language is equivocal, capable of being employed for deception; where there are, generally, more than one meaning for a given word or term. The artist E-40 uses the english language in their published work, though english professor at western academic institution would more than likely not have any clue as to what the english words that the artist creates, combines and uses mean whatsoever; that is, without one or more individuals that might not have a masters or doctorate in english supplied by an english-speaking institution of higher learning the would-be teacher what the words and terms used by the artist mean. The same holds true for the Ancient African Egyptian symbols and scripts, which are claimed to have been "deciphered" by Thomas Young, Champollion, et al. well over a thousand years after the conquest of the Ancient African Egyptians by Alexander of Macedonia. An entire discipline ("Egyptology") was created based on guessing and spurious manufacture after the fact. They have no clue what the words meant to the authors of the symbols, as the authors were never asked and the purported "Egyptologists" were never told the meanings of the sacred symbols by the authors and builders of the scripts and symbols. Some say "TMH" means "created white people" others say the word means "Lybian". Since the Ancient African Egyptian language had no vowels, the user supplies the vowels; the word can have Latin inserted to become "TaMaHu", though since the language is sacred, the Ancient African Egyptians never told or taught their conquerors the original meanings of the terms, and never will. No matter how many times whomever tries to claim they understand those scripts and symbols they can never verify their at best guesses at worse intentional deceit. The manufactured mythologies and outright fraud continue in any direction and field traversed when dealing with specifically english words and terms. Therefore, the english language is not an appropriate example to compare JavaScript, or any specified coding langauge to. 

In any event, re-read the proposal. Am certainly not opposed to the JavaScript language being capable of golf by default. Is the gist of the proposal to substitute ```|>```, and or ```.``` at ```const getEmail = .contacts.email;``` as the first character after ```=``` for `=>`, meaning the initial ```.``` following ```=``` is interpreted as a function call, equivalent to ```=>```? Can you include comments next to the examples at the OP detailing what each character is intended to mean in JavaScript, compared to the current specification of JavaScript?


On Sun, Jun 23, 2019 at 12:13 AM Bob Myers <[hidden email]> wrote:
The world is awash in subjectivity. 

We can nevertheless hope to find broad agreement on at least a transitive ranking of attributes such as readability; if we don't think we can, then we are epistemological nihilists with no criteria whatsoever on which to base our language design decisions and this mailing list would have no raison d'etre, since we would never be able to align on anything.

However subjective the notion of readability, I think few would disagree that the first fragment below is more readable than the second.

```
.name
```

and

```
({name}) => name
```

The first is also more reliable by most measures, because it removes the possibility of misspelling one of the instances of ```name``` in the second, which we would prefer not to rely entirely opn type checkers or linters to pick up.

Yes, to read the first does require additional knowledge, namely of the fact that the syntax ```<dot>property``` denotes a function to retrieve the value of the property by that name. But this is no more a readability problem than the fact that one must have knowledge of the English worrds in a sentence in order for them to be "readable". Such knowledge is often referred to by terms such as "cognitive footprint". Yes, this proposal does have a cognitive footprint. But all language features have cognitive footprints, requiring that people writing and reading code using the feature have knowledge of the feature. The issue then becomes the *size* of the cognitive footprint in relation to the benefit--an equation both sides of which involve subjectivity...

Of course, I did not mean to imply that readability or reliability in and ot themselves are either necessary or sufficient for a new languge feature, There are many other aspects, as many as a dozen, which have been discussed and defined in earlier threads.

Bob

On Sat, Jun 22, 2019 at 12:08 PM guest271314 <[hidden email]> wrote:
> If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.

The term "readable" is entirely subjective. As far as am aware there is no standard for "readable" (in any language, coding or not). Even if such criteria for "readable" did exist in some institutional document, no author of code (or anything else) is bound to recognize or adhere to any such subjective and arbitrary criteria. 

What specific definition of "reliable" is being used, and what are the cases that demonstrates using destructing assignment is not "reliable"? 

On Sat, Jun 22, 2019 at 6:50 PM Bob Myers <[hidden email]> wrote:
On Sat, Jun 22, 2019 at 10:59 AM guest271314 <[hidden email]> wrote:
Does not destructuring assignment provide a means to achieve the requirement?

If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.

_______________________________________________
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

Sanford Whiteman
E-40 uses the preferred pronouns he/him/his. There's no need to muddy
the (40) Waters here.

—— Sandy


_______________________________________________
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

guest271314
U+1F44D

On Sun, Jun 23, 2019 at 2:57 AM Sanford Whiteman <[hidden email]> wrote:
E-40 uses the preferred pronouns he/him/his. There's no need to muddy
the (40) Waters here.

—— Sandy


_______________________________________________
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
In reply to this post by guest271314
> In any event, re-read the proposal. Am certainly not opposed to the JavaScript language being capable of golf by default. Is the gist of the proposal to substitute ```|>```, and or ```.``` at ```const getEmail = .contacts.email;``` as the first character after ```=``` for `=>`, meaning the initial ```.``` following ```=``` is interpreted as a function call, equivalent to ```=>```? Can you include comments next to the examples at the OP detailing what each character is intended to mean in JavaScript, compared to the current specification of JavaScript?

This proposal has nothing to do with ```|>```. It is a variation of dot notation, the classic notation ```o.p``` that has been a feature of JS since its inception, to treat ```.p``` as a function (not a  function call) taking one argument and returning the value of the property ```p``` in that object. To put it a different way, if the object normally preceding the dot is omitted, the construct is treated as a property picking function. It is not a matter of the dot necessarily having to follow an equal sign, or having some special meaning only that context; ```.p``` not preceded by an object is a function regardless of the context. To my knowledge, there is no ambiguity in this notation. In other words, there is no case in which a dot not following an expression and followed by an identifier is anything other than a syntax error at present--please correct me if I'm wrong.

Although not mentioned in the brief propsoal, there is no logical reason that the analogous property access syntax ```.[prop]``` could not be allowed. There also does not seem to any reason to prohibit the use of this construct for arrays, so ```.[0]``` could be the "head" function people have been talking about for years.

Bob

_______________________________________________
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

Naveen Chawla
I am guessing this doesn't allow any operations other than the "dot path" to a function or property... Are you comfortable with that? If so, why? I have found myself doing things like a=>a.x/2 . I couldn't do that in proposed way, could I? Have you found, in your experience, that a "dot path only" return value is common enough to save you a lot of effort, and justify not being easily extendable to accept other operations, other than having to switch to the arrow syntax again, which could be cumbersome?

If you are comfortable with all these things, then I have no problem with the proposal really. I wouldn't lose anything. For me it would be like the "if" clause not requiring curly braces if there's only 1 statement - I simply always use curly braces - and might simply always use arrow functions - for the purposes of extensibility - but I'm not sure.

Thoughts? Have I missed something?

On Sun, 23 Jun 2019 at 07:05, Bob Myers <[hidden email]> wrote:
> In any event, re-read the proposal. Am certainly not opposed to the JavaScript language being capable of golf by default. Is the gist of the proposal to substitute ```|>```, and or ```.``` at ```const getEmail = .contacts.email;``` as the first character after ```=``` for `=>`, meaning the initial ```.``` following ```=``` is interpreted as a function call, equivalent to ```=>```? Can you include comments next to the examples at the OP detailing what each character is intended to mean in JavaScript, compared to the current specification of JavaScript?

This proposal has nothing to do with ```|>```. It is a variation of dot notation, the classic notation ```o.p``` that has been a feature of JS since its inception, to treat ```.p``` as a function (not a  function call) taking one argument and returning the value of the property ```p``` in that object. To put it a different way, if the object normally preceding the dot is omitted, the construct is treated as a property picking function. It is not a matter of the dot necessarily having to follow an equal sign, or having some special meaning only that context; ```.p``` not preceded by an object is a function regardless of the context. To my knowledge, there is no ambiguity in this notation. In other words, there is no case in which a dot not following an expression and followed by an identifier is anything other than a syntax error at present--please correct me if I'm wrong.

Although not mentioned in the brief propsoal, there is no logical reason that the analogous property access syntax ```.[prop]``` could not be allowed. There also does not seem to any reason to prohibit the use of this construct for arrays, so ```.[0]``` could be the "head" function people have been talking about for years.

Bob
_______________________________________________
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
In reply to this post by Bob Myers
Let me correct one thing.

This proposal has nothing to do with ```|>```.

What I meant to say is that the two proposals are not interdependent or related, but since ```.p``` is to be a function retrieving the value of property ```p```, it can be used like any other function in a pipline, and iso n fact plays quite nicely with pipelines.

```
const bedroomSize = house 
  |> getRooms
  |> .bedroom // pick bedroom property from rooms object
  |> calcRoomSize;
```

Bob 

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