Re: Re: Proposal: Selector/Select Expression

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,

Re: Re: Proposal: Selector/Select Expression

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 wrote: > How can the Selector/Select Expression be used with >

Re: Re: Proposal: Selector/Select Expression

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

Re: Re: Proposal: Selector/Select Expression

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

Re: Re: Proposal: Selector/Select Expression

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 wrote: > How can the

Re: Re: Proposal: Selector/Select Expression

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

Re: Re: Proposal: Selector/Select Expression

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 wrote: > Not exactly, since the optional

Re: Re: Proposal: Selector/Select Expression

Not exactly, since the optional chaining operator is `?.` with no space in between. On Thu, Jun 27, 2019 at 1:37 PM Simon Farrugia wrote: > Also, without a leading token, a selector expr with the optional chaining > operator inside a ternary operator would be ambiguous. > > ``` > > const

RE: Re: Proposal: Selector/Select Expression

; es-discuss 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 cont...@isiahmeadows.com www.isiahmeadows.com On Wed, Jun 26, 2019 at 5:44 AM

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 cont...@isiahmeadows.com www.isiahmeadows.com On Wed, Jun 26, 2019 at 5:44 AM Michael Luder-Rosefield wrote: > > The more I read this proposal,

Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

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.

Re: Re: Proposal: Selector/Select Expression

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

Re: Re: Proposal: Selector/Select Expression

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,

Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

> 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

Re: Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

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"

Re: Proposal: Selector/Select Expression

> 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

Re: Proposal: Selector/Select Expression

U+1F44D On Sun, Jun 23, 2019 at 2:57 AM Sanford Whiteman < swhitemanlistens-softw...@figureone.com> 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

Re: Proposal: Selector/Select Expression

E-40 uses the preferred pronouns he/him/his. There's no need to muddy the (40) Waters here. —— Sandy ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

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

Re: Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

> 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

Re: Proposal: Selector/Select Expression

On Sat, Jun 22, 2019 at 10:59 AM guest271314 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.

Re: Proposal: Selector/Select Expression

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 wrote: >

Re: Re: Proposal: Selector/Select Expression

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

Re: Re: Proposal: Selector/Select Expression

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

Re: Re: Proposal: Selector/Select Expression

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.

Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

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

Re: Proposal: Selector/Select Expression

ems unusual -- Původní e-mail -- Od: Scott Rudiger Komu: Simon Farrugia Datum: 21. 6. 2019 15:30:53 Předmět: Re: Proposal: Selector/Select Expression " I can appreciate the intent of the proposal.  Minor nit with one of the examples: // user[] => email[] (

Re: Proposal: Selector/Select Expression

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