Re: Ternary operator enhancement proposal

[Jacob Pratt]

Aside from the fact that using a non-reserved identifier would break
back-compatibility, I'm fairly certain pattern matching would allow for not
recalculating the value while also being far more readable.

On Tue, Nov 12, 2019, 21:43 devlato  wrote:

> Hey folks,
>
> not sure if you haven't discussed something similar, but what do you think
> about making an enhancement for the ternary operator, to make it more
> powerful?
> I've created a small explanatory doc on GitHub:
> https://github.com/devlato/proposal-ternary-placeholder
>
> Warmest regards,
> Denis
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: syntactic sugar for extracting fields from objects

[Jacob Pratt]

Is there any interest from a TC39 member with regards to a possible pick
notation or `Object.pick` method? It's been something proposed a few times
over, typically using similar syntax, and seems to have broad support.

At the very least, couldn't this become a stage 0 proposal? Bob has already
created a [repository], and the [process document] specifies no entrance
criteria for stage 0. If a champion were identified, stage 1 doesn't seem
far off.

[repository]: https://github.com/rtm/js-pick-notation
[process document]: https://tc39.es/process-document/

Jacob Pratt


On Wed, Jun 5, 2019 at 5:59 AM Isiah Meadows  wrote:

> Nit: 2A will reject thanks to TDZ semantics with `name` in the RHS
> where it's defined in the LHS of the same statement. (Think of the
> function body's lexical context as being in a block where parameters
> are in a parent block context. The block variable shadows the parent
> variable for the whole block and just initially starts as unset.) So
> that error *will* get caught fairly quickly.
>
> But aside from that:
>
> I agree 1A is a bit too noisy, especially in the parameter side.
>
> 1B could be simplified a bit. Have you considered leveraging the
> existing object rest+spread and just standard property accesses? This
> is technically shorter than your suggestion and is much less
> cluttered. (I do see a frequent pattern of premature destructuring
> when it's shorter, easier, and simpler *not* to.)
>
> ```
> return {...state.user.{firstName, lastName}, url:
> state.common.currentPageURL}
> ```
>
> 2A could be fixed to work like this, which is technically shorter than
> your example:
>
> ```
> const resp = await sendToServer({name})
> return {ok: true, payload: {name: resp.name}}
> ```
>
> And likewise, you could simplify 2B to this:
>
> ```
> const resp = await sendToServer({name})
> return {ok: true, payload: resp.{name}}
> ```
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Tue, May 28, 2019 at 3:13 PM Григорий Карелин 
> wrote:
> >
> > Here are another examples, where "destructuring picking" I suggest
> whould be helpful.
> > ==1A Now (redux related)
> > ```
> > function mapStateToProps({user: {firstName, lastName}, common:
> {currentPageURL: url}}) {
> >   return {firstName, lastName, url};
> > }
> > ```
> > ==1B Proposal
> > ```
> > function mapStateToProps(state) {
> >   return {{firstName, lastName from state.user}, {currentPageURL as url
> from state.common}};
> > }
> > ```
> >
> > Shorter!
> >
> > ==2A Now
> > ```
> > async function saveNewUserName(name) {
> >   const {name} = await sendToServer({name});
> >
> >   return {ok: true, payload: {name}}; // oh wait, which name is it
> again? Argument or response?
> > }
> > ```
> > == 2B Proposal
> > ```
> > async function saveNewUserName(name) {
> >   const resp = await sendToServer({name});
> >
> >   return {ok: true, {name from response}};
> > }
> > ```
> > No accidental shadowing.
> >
> > I know, I know, you can achieve all that without new syntax, via naming
> your variables properly and using long explicit expressions. But I think
> some sugar won't hurt.
> > After all, remember destructuring? There's no reason to use it other
> than it's cool and short and expressive.
> >
> >
> > вт, 28 мая 2019 г. в 21:49, guest271314 :
> >>>>
> >>>> ```
> >>>> let obj = {otherData: "other data"};
> >>>> ({firstName:obj.firstName, lastName:obj.lastName} = user.profile);
> >>>> ```
> >>>>
> >>>> I don't understand this.
> >>
> >>
> >>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Assigning_to_new_variable_names
> >>
> >>> He's looking for a terser
> >>
> >>
> >> Is the proposal to golf destructuring assignment?
> >>
> >> The proposed destructuring assignment syntax example is 25 characters
> less than the non-destructing assignment example, which is terser.
> >>
> >> One observation about the proposed syntax is that the values set at the
> target object would be set from the identifier on the left side of
> ```from``` which is similar to
> >>
> >> ```
> >> var o = {x:1};
> >> console.log(o.x = 2); // 2
> >> ```
> >>
> >> though how will the property name be set at the object at target object
> instead of `{"2":2}`? How does the engine kno

Re: `String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

[Jacob Pratt]

Just thinking about this, the argument that it could be done with regex
would also apply to spaces. It's by no means an argument _in favor_, but it
clearly wasn't a blocker.

On Mon, Jun 24, 2019 at 4:10 PM kai zhu  wrote:

> fyi, a search of the entire markedjs/marked repo shows 2 places where
> rtrim is used:
>
> ```js
> // https://github.com/markedjs/marked/blob/master/lib/marked.js
> 227
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L227>
> codeBlockStyle: 'indented',
> 228
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L228>
> text: !this.options.pedantic
> 229
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L229>
> ? rtrim(cap, '\n')
> 230
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L230>
> : cap
> …
> 1425
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1425>
> baseUrls[' ' + base] = rtrim(base, '/', true);
> 1426
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1426>
>  }
>
> 1427
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1427>
>  }
>
> 1428
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1428>
>  base
> = baseUrls[' ' + base];
> 1429
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1429>
> 1430
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1430>
> if (href.slice(0, 2) === '//') {
> ```
>
> only the 1st use-case does what this thread proposes (the 1st trimRight's
> "\n", while the 2nd behaves differently and is more like nodejs'
> `require("path").dirname()`
>
> if i were writing the library, i wouldn't have bothered with a
> helper-function if its only going to show up in 2 [trivial] places.
> would've instead inlined two throwaway regexp-expressions, to keep code
> more-self-contained / less-fragmented:
>
> ```js
> 228  text: !this.options.pedantic
> 229? cap.replace((/\n+$/), "") // remove trailing "\n" or
> perhaps just use .trimRight()
> 230: cap
> …
> 1425  baseUrls[' ' + base] = base.replace((/\/[^\/]*$/), "/"); // get
> "dirname" of base-url
> 1426}
> ```
>
> On Mon, Jun 24, 2019 at 2:27 PM Jacob Pratt  wrote:
>
>> No idea how common of a use case this is; I personally ran across it when
>> reviewing the source code for marked (specifically the [rtrim method]).
>> That example only does characters, not strings, but it's used in the wild
>> by a package with ~2m weekly downloads on npm.
>>
>> Of course we wouldn't want `trimStart` to differ from `trimLeft`, they'd
>> all be modified in unison. I just think that symmetry between similar
>> methods is important, and (apparently) has use cases.
>>
>> [rtrim method]:
>> https://github.com/markedjs/marked/blob/master/lib/marked.js#L1493-L1517
>>
>> On Mon, Jun 24, 2019 at 12:46 AM Jordan Harband  wrote:
>>
>>> `trimStart` and `trimEnd` are better-named versions of the very very
>>> long-existing `trimLeft` and `trimRight`, which lack this ability, along
>>> with ES5's `trim`.
>>>
>>> It wouldn't make sense for these three to differ.
>>>
>>> It certainly seems like a potential language proposal to add a string
>>> argument to all three; however, at what point is that reimplementing
>>> `string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and
>>> `string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to
>>> trim matching substrings off of the ends of a string? (the use cases for
>>> padding were quite common)
>>>
>>> On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt 
>>> wrote:
>>>
>>>> `String.prototype.padStart` and `String.prototype.padEnd` accept the
>>>> string to pad with as their final parameter. Is there any particular reason
>>>> `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the
>>>> same? It would be nice to have a parallel, such that `'foo'.padEnd(10,
>>>> 'bar').trimEnd('bar') === 'foo'`.
>>>>
>>>> References:
>>>> - https://github.com/tc39/proposal-string-pad-start-end
>>>> - https://github.com/tc39/proposal-string-left-right-trim
>>>>
>>>> Jacob Pratt
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

[Jacob Pratt]

No idea how common of a use case this is; I personally ran across it when
reviewing the source code for marked (specifically the [rtrim method]).
That example only does characters, not strings, but it's used in the wild
by a package with ~2m weekly downloads on npm.

Of course we wouldn't want `trimStart` to differ from `trimLeft`, they'd
all be modified in unison. I just think that symmetry between similar
methods is important, and (apparently) has use cases.

[rtrim method]:
https://github.com/markedjs/marked/blob/master/lib/marked.js#L1493-L1517

On Mon, Jun 24, 2019 at 12:46 AM Jordan Harband  wrote:

> `trimStart` and `trimEnd` are better-named versions of the very very
> long-existing `trimLeft` and `trimRight`, which lack this ability, along
> with ES5's `trim`.
>
> It wouldn't make sense for these three to differ.
>
> It certainly seems like a potential language proposal to add a string
> argument to all three; however, at what point is that reimplementing
> `string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and
> `string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to
> trim matching substrings off of the ends of a string? (the use cases for
> padding were quite common)
>
> On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt  wrote:
>
>> `String.prototype.padStart` and `String.prototype.padEnd` accept the
>> string to pad with as their final parameter. Is there any particular reason
>> `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the
>> same? It would be nice to have a parallel, such that `'foo'.padEnd(10,
>> 'bar').trimEnd('bar') === 'foo'`.
>>
>> References:
>> - https://github.com/tc39/proposal-string-pad-start-end
>> - https://github.com/tc39/proposal-string-left-right-trim
>>
>> Jacob Pratt
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

`String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

[Jacob Pratt]

`String.prototype.padStart` and `String.prototype.padEnd` accept the string
to pad with as their final parameter. Is there any particular reason
`String.prototype.trimStart` and `String.prototype.trimEnd` don't do the
same? It would be nice to have a parallel, such that `'foo'.padEnd(10,
'bar').trimEnd('bar') === 'foo'`.

References:
- https://github.com/tc39/proposal-string-pad-start-end
- https://github.com/tc39/proposal-string-left-right-trim

Jacob Pratt
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: RegExp `x` flag

[Jacob Pratt]

With regards to a minifier, I see no reason it couldn't compact it to the
regex we have today. After all, the only changes are the addition of
whitespace and comments.

I can't speak as to parse time, though in production that would large be
removed by the aforementioned minification.

String concatenation certainly works, but then any escapes have to be
doubly so, else you use `String.raw` on template literals in every
situation, quickly cluttering things back up.


On Tue, Jun 4, 2019, 00:36 kai zhu  wrote:

> 1. is this minifier-friendly?
> 2. is parsing-impact minimal enough to not affect load-times?
> regexp-detection/bounding is among the most expensive/complex part of
> javascript-parsing.
>
> those 2 nits aside, i'm on the fence.  regexp-spaghetti is a valid
> painpoint, and jslint's author has expressed desire for multiline regexp
> [1].  otoh, there is a good-enough solution by falling-back to
> constructor-form to improve readability:
>
> ```js
> // real-world spaghetti-regexp code in jslint.js
> const rx_token =
> /^((\s+)|([a-zA-Z_$][a-zA-Z0-9_$]*)|[(){}\[\],:;'"~`]|\?\.?|=(?:==?|>)?|\.+|[*\/][*\/=]?|\+[=+]?|-[=\-]?|[\^%]=?|&[&=]?|\|[|=]?|>{1,3}=?|<
> // vs
>
> /*
>  * break JSON.stringify(rx_token.source)
>  * into multiline constructor-form for readability
>  */
> const rx_token = new RegExp(
> "^("
> + "(\\s+)"
> + "|([a-zA-Z_$][a-zA-Z0-9_$]*)"
> + "|[(){}\\[\\],:;'\"~`]"
> + "|\\?\\.?"
> + "|=(?:==?|>)?"
> + "|\\.+"
> + "|[*\\/][*\\/=]?"
> + "|\\+[=+]?"
> + "|-[=\\-]?"
> + "|[\\^%]=?"
> + "|&[&=]?"
> + "|\\|[|=]?"
> + "|>{1,3}=?"
> + "|< + "|!(?:!|==?)?"
> + "|(0|[1-9][0-9]*)"
> + ")(.*)$"
> );
> ```
>
> [1] github jslint-issue #231 - ignore long regexp's (and comments)
> https://github.com/douglascrockford/JSLint/pull/231#issuecomment-421881426
>
>
>
>
> On Mon, Jun 3, 2019 at 10:27 PM Jacob Pratt  wrote:
>
>> Even if this flag were restricted to constructors instead of both
>> constructors and literals, it could be worthwhile.
>>
>> On Mon, Jun 3, 2019, 23:19 Isiah Meadows  wrote:
>>
>>> Let me clarify that previous message: I mean "newline restriction" in
>>> the sense that newlines are not permitted in regexp literals. A `/x`
>>> flag would make removing it practically required for it to have any
>>> utility.
>>>
>>> -
>>>
>>> Isiah Meadows
>>> cont...@isiahmeadows.com
>>> www.isiahmeadows.com
>>>
>>> On Mon, Jun 3, 2019 at 11:14 PM Isiah Meadows 
>>> wrote:
>>> >
>>> > I would personally love this (as well as interpolations in regexp
>>> > literals). I do have a concern about whether removing the newline
>>> > restriction creates ambiguities with division, but I suspect this is
>>> > *not* the case.
>>> >
>>> > -
>>> >
>>> > Isiah Meadows
>>> > cont...@isiahmeadows.com
>>> > www.isiahmeadows.com
>>> >
>>> > On Mon, Jun 3, 2019 at 10:03 PM Jacob Pratt 
>>> wrote:
>>> > >
>>> > > Has there been any previous discussion of adding the `x` flag to JS?
>>> It exists in other languages, and can make relatively complicated regex
>>> _much_ easier to read. It also allows for comments, which are incredibly
>>> helpful when trying to understand some regexes.
>>> > >
>>> > > For prior art, XRegExp has this flag (though I've no idea to figure
>>> out how frequently it's used), as do a few other languages.
>>> > >
>>> > > Quick overview:
>>> https://www.regular-expressions.info/freespacing.html
>>> > >
>>> > > Language references:
>>> > > Python: https://docs.python.org/3/library/re.html#re.X
>>> > > Rust: https://docs.rs/regex/1.1.6/regex/
>>> > > XRegExp: http://xregexp.com/xregexp/flags/#extended
>>> > > .NET:
>>> https://docs.microsoft.com/en-us/dotnet/standard/base-types/regular-expression-language-quick-reference#regular-expression-options
>>> > >
>>> > > Jacob Pratt
>>> > > ___
>>> > > es-discuss mailing list
>>> > > es-discuss@mozilla.org
>>> > > https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: RegExp `x` flag

[Jacob Pratt]

Even if this flag were restricted to constructors instead of both
constructors and literals, it could be worthwhile.

On Mon, Jun 3, 2019, 23:19 Isiah Meadows  wrote:

> Let me clarify that previous message: I mean "newline restriction" in
> the sense that newlines are not permitted in regexp literals. A `/x`
> flag would make removing it practically required for it to have any
> utility.
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Mon, Jun 3, 2019 at 11:14 PM Isiah Meadows 
> wrote:
> >
> > I would personally love this (as well as interpolations in regexp
> > literals). I do have a concern about whether removing the newline
> > restriction creates ambiguities with division, but I suspect this is
> > *not* the case.
> >
> > -
> >
> > Isiah Meadows
> > cont...@isiahmeadows.com
> > www.isiahmeadows.com
> >
> > On Mon, Jun 3, 2019 at 10:03 PM Jacob Pratt 
> wrote:
> > >
> > > Has there been any previous discussion of adding the `x` flag to JS?
> It exists in other languages, and can make relatively complicated regex
> _much_ easier to read. It also allows for comments, which are incredibly
> helpful when trying to understand some regexes.
> > >
> > > For prior art, XRegExp has this flag (though I've no idea to figure
> out how frequently it's used), as do a few other languages.
> > >
> > > Quick overview: https://www.regular-expressions.info/freespacing.html
> > >
> > > Language references:
> > > Python: https://docs.python.org/3/library/re.html#re.X
> > > Rust: https://docs.rs/regex/1.1.6/regex/
> > > XRegExp: http://xregexp.com/xregexp/flags/#extended
> > > .NET:
> https://docs.microsoft.com/en-us/dotnet/standard/base-types/regular-expression-language-quick-reference#regular-expression-options
> > >
> > > Jacob Pratt
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RegExp `x` flag

[Jacob Pratt]

Has there been any previous discussion of adding the `x` flag to JS? It
exists in other languages, and can make relatively complicated regex _much_
easier to read. It also allows for comments, which are incredibly helpful
when trying to understand some regexes.

For prior art, XRegExp has this flag (though I've no idea to figure out how
frequently it's used), as do a few other languages.

Quick overview: https://www.regular-expressions.info/freespacing.html

Language references:
Python: https://docs.python.org/3/library/re.html#re.X
Rust: https://docs.rs/regex/1.1.6/regex/
XRegExp: http://xregexp.com/xregexp/flags/#extended
.NET:
https://docs.microsoft.com/en-us/dotnet/standard/base-types/regular-expression-language-quick-reference#regular-expression-options

Jacob Pratt
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: syntactic sugar for extracting fields from objects

[Jacob Pratt]

My understanding is that Babel does support proposals, even if they require
new syntax. Of course, it would require changes to the parser that's beyond
my understanding of the codebase. I'd certainly help out in whatever ways
I'm able to.

For the record, though, I actually had this idea completely separate from
the proposal — I ran across it when searching to see if anyone else had
proposed such a syntax/language feature.

On Thu, May 30, 2019, 14:24 Bob Myers  wrote:

> I don't know what "community" means, other than a bunch of people
> subscribing to this ML, and I can't imagine how one would define, or
> achieve, or identify, a "consensus" of that community, or why or how the
> community would vote on anything, or what such the results of such a vote
> would mean.
>
> The very next step is to identify a champion. Such a champion would
> presumably help to shape, review, and choose between alternatives for the
> proposals. However, given the failure of my half-hearted efforts to find a
> champion, and the fact that no one has emerged as champion over the several
> years since these discussions started, allow me to be pessimistic.
>
> It's odd to me because features such as property spread/rest notation, and
> before that destructuring, have clearly demonstrated the appetite of the
> "community" for language changes to better support manipulation of
> properties--not surprising, since objects and their properties can be
> considered the fundamental data structures of the language. This specific
> proposal has a relatively small syntactic footprint in my opinion, and
> measures up well against the majority of criteria that people commonly
> apply to language design decisions and have been documented on this list. I
> can only conclude that wiser minds than my own have concluded that this
> particular feature simply does not rise to the level of priority of other
> features that are progressing down the pipeline.
>
> WIth regard to the notion of implementing this feature on a test basis,
> the most obvious approach to doing that is as a Babel plug-in, but based on
> my research--please-correct me if I'm wrong--Babel supports many kind of
> transformations but not entirely new syntax as is the case here; that
> requires essentialy rewriting internal parts of its parser. I have
> experimented with a Sweet implementation with some success, but actually
> I'm not really sure what that is supposed to demonstrate or if anyone would
> care.
>
> Bob
>
> On Thu, May 30, 2019 at 12:29 AM guest271314 
> wrote:
>
>> Not a rule. Just an email to this board.
>>
>> On Thu, May 30, 2019 at 7:26 AM Григорий Карелин 
>> wrote:
>>
>>> I'm new to this community, so I'd appreciate if you clarify: is that
>>> your opinion or is it kind of rule written somewhere?
>>>
>>> чт, 30 мая 2019 г. в 09:59, guest271314 :
>>>
 > Wouldn't it be better to consolidate the decision? I mean as OP I
 vote for `from`, but if majority will say they better like `x.{y, z}` I'll
 take it.

 No. There should not be any prohibition as to the additions different
 solutions to a single proposal. Neither proposal is "better" right now as
 neither have been coded, tested, and if necessary, specified. A simple
 majority does not mean correct or complete. The more approaches available
 the more ability to compose the code from different perspectives,
 outputting the same result; expanding the language both in syntax and reach
 as to possible composition, without setting an arbitrary specification to a
 single majority at only this point in time.

 The tersest have been able to achieve so far on a single line using an
 immediately invoked arrow function and object rest which requires writing
 the identifier twice.

 If part of the requirement for the proposal is terse code, following
 the pattern of an immediately invoked arrow function if  ```=``` operator
 between expressions ```()``` the arrow `>` and return value could be
 omitted as being designated implicit immediately invoked arrow function
 with default return value set from the destructured parameters, or
 ```undefined``` set as value of target identifiers, or plain object
 ```{}```, resulting in the syntax, within at least an object literal,
 possibly preceded by spread syntax, will result in

 ```let obj = {otherData:'other
 data',...(({firstName,lastName})=(user.profile)}```

 being equivalent to

 ```let obj = {otherData:'other
 data',...(({firstName,lastName})=>({firstName,lastName}))(user.profile)}```


 On Thu, May 30, 2019 at 6:38 AM Григорий Карелин 
 wrote:

> Wouldn't it be better to consolidate the decision? I mean as OP I vote
> for `from`, but if majority will say they better like `x.{y, z}` I'll take
> it.
>
> чт, 30 мая 2019 г. в 06:35, guest271314 :
>
>> > I think it's possible to find someone who will 

Re: Re: Proposal: native XML object support.

[Jacob Pratt]

JSX doesn't necessarily need a vDOM.

On Tue, May 21, 2019, 10:31 kai zhu  wrote:

> jsx is not terribly javascripty ... vs direct manipulation of the dom
> (using static-functions/handlers).
>
> it requires two extra ux-workflow transformations -- 1) transpilation and
> 2) virtual-dom manipulation, for the sake of oft-quoted faster
> dom-performance, which some like me are skeptical is true in modern
> browsers.
>
> -kai
>
>
> On Tue, May 21, 2019, 16:35 Andrea Giammarchi 
> wrote:
>
>> People use JSX, which is basically E4X, so I'd argue the word useless is
>> not really appropriate. You can use E4X to produce HTML, the fact we're
>> talking XML is merely about the E4X background, but as you could produce
>> strings out of E4X you could do the same and have better templating out of
>> the box.
>>
>> But like I've said, I already use template literal tags, but those
>> strings don't get hints or highlights as if these were E4X, XML, or plain
>> HTML, which is the only cool thing I'd personally find useful.
>>
>> Maybe it's just a tooling issue though.
>>
>> On Mon, May 20, 2019 at 3:06 PM ViliusCreator <
>> viliuskubilius...@gmail.com> wrote:
>>
>>> > the client, it could still somehow shine in NodeJS though.
>>>
>>>
>>>
>>> The only way it can shine is only passing HTML objects as arg to
>>> website. That’s it. And still, you can use string to do that for you.
>>> People already use JSON and I don’t think they would use XML in Node js.
>>> There are already tons of libs for XML stuff, yet they don’t have a lot of
>>> downloads, as far as I remember.
>>>
>>>
>>>
>>> So basically, Node js doesn’t need XML. That would be useless.
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: switch statement multiple

[Jacob Pratt]

https://github.com/tc39/proposal-pattern-matching

On Sat, Feb 16, 2019 at 4:02 AM Juan Pablo Garcia 
wrote:

> I think it would be great if the switch statement allows multiple argument
>
> Example
> Switch(a,b)
> Case: 1,true
> Case: 1,false
> Case: 2,true
> 
>
>
> Switch (true, true)
> Case: isPremium,  true
> Case: isBasic, hasCredit
> Case: isBasic, !hasCredit
>
>
> Maybe case: default, true
>
> Look forward to read yours views.
>
>
>
> I used to code in cobol and was very useful the sintax
> COBOL example:
> Evaluate a also b
> When 1 also true
> When any also false
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New: proposal-common-member-modifiers

[Jacob Pratt]

I'm of the opinion this is what decorators are for.

On Sun, Dec 2, 2018, 01:49 Ranando King  Since some form of data is going to land in ES class syntax, it would be a
> good idea if the capabilities of a property descriptor were also exposed
> for all public properties.
>
> https://github.com/rdking/proposal-common-member-modifiers
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Proposal: Number.range (Yes, range again)

[Jacob Pratt]

I'm not saying we should add it on to that proposal, but rather saying that
I think more effort should be put into a standard library where things like
this don't need to go through a full standards process. That's just my
opinion, and borderline on-topic for this specific suggestion.

I'm absolutely in favor of having a `range` method, it's just _where_ it
should be that I differ.

Jacob Pratt

On Thu, Nov 29, 2018 at 4:29 AM Jack Works  wrote:

> Oh, I'm not here to find out how to implement a range in detail. That's
> the trivial things, I want to first make it become a stage 0 proposal, then
> we can discuss if we need some overload or how to deal with the edge cases.
> Ps, does Pratt mean we should add it as a standard library in the stage 1
> standard libraray proposal?
>
> On Thu, Nov 29, 2018, 12:18 Jacob Pratt  wrote:
>
>> Quick, simple TypeScript range function (with overloads, of course).
>>
>> ```
>> export function range(end: number): IterableIterator;
>> export function range(start: number, end: number):
>> IterableIterator;
>> export function range(start: number, end: number, step: number):
>> IterableIterator;
>> export function* range(start: number, end?: number, step?: number):
>> IterableIterator {
>>   // overload #1
>>   if (end === undefined) {
>> [start, end, step] = [0, start, 1];
>>   }
>>
>>   // overload #2
>>   if (step === undefined) {
>> step = Math.sign(end - start);
>>   }
>>
>>   // ensure we have the appropriate types
>>   if (typeof start !== 'number' || typeof end !== 'number' || typeof step
>> !== 'number') {
>> throw new TypeError('all parameters must be of type number');
>>   }
>>
>>   while ((start < end && step > 0) || (start > end && step < 0)) {
>> yield start;
>> start += step;
>>   }
>> }
>> ```
>>
>> IMO, we should focus on building up a JavaScript standard library that
>> has tons of useful utilities like this, rather than continue to add methods
>> onto namespaces. Perhaps that's just me, though.
>>
>> Jacob Pratt
>>
>> On Wed, Nov 28, 2018 at 9:33 PM Tab Atkins Jr. 
>> wrote:
>>
>>> I end up writing a range function in virtually every project I use, so
>>> yeah, I think this is worthwhile.
>>>
>>> My own preferences, based on Python precedence:
>>>
>>> Number.range(end) === Number.range(0, end, 1)
>>> Number.range(start, end) === Number.range(start, end,
>>> Math.sign(end-start))
>>> Number.range(start, end, step) => {
>>>   if start < end && step > 0: yield all (start + k*step), for k from 0
>>> to infinity, less than end
>>>   elif start > end && step < 0: yield all (start + k*step), for k from
>>> 0 to infinity, greater than end
>>>   else: yield nothing
>>> }
>>>
>>> So:
>>> * [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
>>> * [...Number.range(0)] evaluates to []
>>> * [...Number.range(-5)] evaluates to []
>>> * [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
>>> * [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
>>> * [...Number.range(1, 1)] evaluates to []
>>> * [...Number.range(0, 10, 5)] evaluates to [0, 5]
>>> * [...Number.range(0, 10, -5)] evaluates to []
>>>
>>> ~TJ
>>>
>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Proposal: Number.range (Yes, range again)

[Jacob Pratt]

Quick, simple TypeScript range function (with overloads, of course).

```
export function range(end: number): IterableIterator;
export function range(start: number, end: number): IterableIterator;
export function range(start: number, end: number, step: number):
IterableIterator;
export function* range(start: number, end?: number, step?: number):
IterableIterator {
  // overload #1
  if (end === undefined) {
[start, end, step] = [0, start, 1];
  }

  // overload #2
  if (step === undefined) {
step = Math.sign(end - start);
  }

  // ensure we have the appropriate types
  if (typeof start !== 'number' || typeof end !== 'number' || typeof step
!== 'number') {
throw new TypeError('all parameters must be of type number');
  }

  while ((start < end && step > 0) || (start > end && step < 0)) {
yield start;
start += step;
  }
}
```

IMO, we should focus on building up a JavaScript standard library that has
tons of useful utilities like this, rather than continue to add methods
onto namespaces. Perhaps that's just me, though.

Jacob Pratt

On Wed, Nov 28, 2018 at 9:33 PM Tab Atkins Jr.  wrote:

> I end up writing a range function in virtually every project I use, so
> yeah, I think this is worthwhile.
>
> My own preferences, based on Python precedence:
>
> Number.range(end) === Number.range(0, end, 1)
> Number.range(start, end) === Number.range(start, end, Math.sign(end-start))
> Number.range(start, end, step) => {
>   if start < end && step > 0: yield all (start + k*step), for k from 0
> to infinity, less than end
>   elif start > end && step < 0: yield all (start + k*step), for k from
> 0 to infinity, greater than end
>   else: yield nothing
> }
>
> So:
> * [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
> * [...Number.range(0)] evaluates to []
> * [...Number.range(-5)] evaluates to []
> * [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
> * [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
> * [...Number.range(1, 1)] evaluates to []
> * [...Number.range(0, 10, 5)] evaluates to [0, 5]
> * [...Number.range(0, 10, -5)] evaluates to []
>
> ~TJ
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Why isn't `Promise.all()` overloaded?

[Jacob Pratt]

This is potentially a very simple question, `Promise.all()` takes a single
iterable as a parameter. Is there any particularly reason it wasn't
overloaded to allow passing multiple parameters (and use `...arguments`)?
Of course, the only difference is the creation of an array, but it *is* an
array that doesn't need to be created.

Jacob Pratt
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [proposal] Object.pick

[Jacob Pratt]

Unsure if this is even still being actively weekend out, but I've played
around with the binding operator in Babel for this purpose. It definitely
has its use case; mine was filtering allowed keys for a REST API.

On Wed, Jul 25, 2018, 19:54 Mikkel Davis  wrote:

> Thanks for the heads up! As I mentioned above, I've seen it come up
> before, but all the top results when searching are syntactic proposals.
> Syntax would be cool and all, but like you said it may or may not be
> justified. In the mean time, I don't see any traction for an Object util
> proposal like this. Does anybody know if this specifically has come up
> before and if there is a big reason against it?
> ---
> Mikkel R. Davis
>
>
> On Wed, Jul 25, 2018 at 5:42 PM Isiah Meadows 
> wrote:
>
>> Just as a heads up, this has come up plenty of times before, both as a
>> function and (usually) syntax:
>> https://www.google.com/search?q=site%3Aesdiscuss.org+pick
>>
>> I'm good with it being a built-in function, but it's harder to justify
>> using syntax apart from an easier time building up the relevant type
>> ICs.
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>> www.isiahmeadows.com
>>
>>
>> On Wed, Jul 25, 2018 at 5:45 PM, Mikkel Davis  wrote:
>> > I've seen proposals for syntax additions that give functionality
>> similar to
>> > lodash's "pick" utility. But I think it may be more appropriate to add
>> it as
>> > an Object utility in the same vein of `Object.assign`, `Object.keys`,
>> > `Object.values`. After a quick search, I was surprised to not find an
>> > existing proposal like this. Why would that be?
>> >
>> > For me, this isn't just one of those "huh, that's a neat lodash util
>> that
>> > would be nifty to have natively." The codebase I work on most often
>> already
>> > has lodash everywhere, and I have found myself utilizing _.pick
>> frequently,
>> > e.g. mapping or passing down portions of React state or props. I really
>> > think is common enough that it justifies addition to the spec.
>> >
>> > ```js
>> > const person = {
>> > first: 'Marie',
>> > last: 'Curie',
>> > age: 51,
>> > address: 'Grenoble, France',
>> > };
>> >
>> > Object.pick(person, ['first', 'age']);  // {first: "Marie", age: 51}
>> > ```
>> >
>> > The only other concise way to do this I can think of, using latest ES is
>> > `(({first, age}) => ({first, age}))(person)`, which is quite
>> undesirable,
>> > for a variety of reasons.
>> >
>> > Another name that might be nice is `Object.slice`.
>> >
>> > ---
>> > Mikkel R. Davis
>> >
>> > ___
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: javascript vision thing

[Jacob Pratt]

Mostly a lurker here. I fully agree with your points, and also use JS for
non-web projects.

On Wed, Jul 25, 2018, 07:34 T.J. Crowder 
wrote:

> Lurkers: If I'm alone in this, please say so. If I'm **not** alone, please
> say so (publicly this time). Either way, I'm done as of this message other
> than linking back to it.
>
> On Wed, Jul 25, 2018 at 11:33 AM, kai zhu
>  wrote:
> > there is no foreseeable future where javascript will be a better tool
> > than java/c++/python/etc. for non web-related projects.  there is no
> > foreseeable future where employers would hire nodejs-developers to
> > work on non web-related projects
>
> This is where we differ (well, one place we differ), as I've said many
> times before, and others have said many times before. That future is now.
>
> How we got here is irrelevant. Where we **are** is that JavaScript is a
> general-purpose programming language good for a lot more than just
> web-related work. And "web" technologies are used for a lot more than just
> the web, witness all those mobile app frameworks using HTML/CSS/JavaScript,
> Windows store apps, Electron, etc. It's also a good language for writing
> *nix shell scripts and command-line utilities, particularly now that it has
> `async`/`await`. There are at least a dozen JavaScript engines for doing
> embedded device work, completely removed from the web environment. And so
> on.
>
> Separately, the idea that web projects don't benefit from features like
> `class`, `async`/`await`, and meta-programming features and such is flatly
> contradicted by the evidence.
>
> But leave all that aside. We all know you don't agree with that. You've
> told us, ad nauseum. It's not that we haven't heard what you're saying,
> it's that we disagree with it. (I say "we" because I've had private
> messages from people supporting my pushback on this. I wish they'd be made
> publicly.) Taking every vague opportunity to push your view of JavaScript
> as a niche, limited language is not constructive at this point.
> Robustly-expressed differing views are an essential part of
> consensus-building, but there comes a point where one has to accept that
> one's view has not been successful *and move on*. I think frankly we're
> well past that point on this topic, and have been for a while. Specific
> input on proposals is great, including raising specific concerns with
> serialization etc. (ideally with a proposed solution, but sometimes just
> raising a concern is useful). Putting forward constructive, specific
> proposals for things you think TC39 should be acting on is great.
> Constantly trying to push a view clearly at odds with the consensus of the
> community here is just not useful, and gets in the way of useful
> conversations we could be having, including about the things you care about
> getting done. Please, please move on.
>
> And again: I think you're right that issues around JSON interop with new
> features like BigInt need focus (here, in the proposal itself, in some JSON
> working group, somewhere), and there seems to be interest in doing so. So
> if that's an area of interest for you, please contribute to that effort,
> rather than spending time beating this dead horse.
>
> I'm not going to keep writing these replies, I'll just refer to this one
> from now on.
>
> And again, lurkers, please weigh in.
>
> -- T.J. Crowder
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Small Proposal "!in"

[Jacob Pratt]

> Throwing another operator name out there: what about `obj has "foo"`
instead?

As someone who has just been casually following this issue, I'd much prefer
`has` over `on`. I was going to stay quiet, but only because I didn't have
a better alternative.

jhpratt

On Thu, Jul 19, 2018 at 8:56 PM, Isiah Meadows 
wrote:

> > "on" is a good name.  Agree on separate.
>
> Throwing another operator name out there: what about `obj has "foo"`
> instead?
>
> Either way, it's a new context-sensitive keyword in a very awkward
> position.
>
> > * Non-clobbering mass assignment.  Like Object.assign but that doesn't
> > overwrite existing properties in the assignee.
>
> Could this be a new built-in function instead? Maybe, `Object.defaults`?
>
> Of course, this is a pretty hard tangent from the original thread.
>
> > Many use cases for hasOwnProperty could be better supported by Map, Set,
> and
> > Object.create(null) including:
> > ...
> > * Configuration objects.
> > * Function options bundles.
>
> Not sure these would work well as maps, since it's far easier to just
> use dictionary objects as named arguments. Clojure and Ruby are the
> two main languages I know that use hash maps exclusively for named
> parameters with any frequency, and that's because map/hash lookup is
> as easy as property lookup.
>
> - Java and C++ use builders. (Java separates the two, while C++ merges
> them.)
> - C and Rust use structs.
> - JavaScript and Lua use simple untyped objects.
> - Kotlin, Scala, Swift, C#, Python, and Objective C use native named
> arguments that are resolved internally.
> - Even Ruby added sugar to support its common idiomatic use of hashes
> as named arguments.
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Thu, Jul 19, 2018 at 1:03 PM, Mike Samuel  wrote:
> >
> >
> > On Thu, Jul 19, 2018 at 11:56 AM Michael Theriot
> >  wrote:
> 
>  For me, `hasOwn` with the different operand order isn't a problem, but
>  others may take a different view. Trying to keep the same order takes
> us
>  down a route like `inOwn` which I can't say I care for.
> >>>
> >>>
> >>> Nor me. I would argue for `on` (`'a' on b`), but that is a huge typo
> >>> footgun (especially for Colemak users) and maybe isn't clear enough
> about
> >>> its semantics.  I would argue that operators aren't camel cased in JS
> >>> though, so `hasown`/`inown`.
> >>
> >>
> >> For what it's worth I was also thinking of an "on" operator when reading
> >> this message, so this is intuitive to me. I also think that is a
> separate
> >> idea to propose though.
> >
> >
> > "on" is a good name.  Agree on separate.
> >
> >
> 
>  Of couse the usage of `in` is most of the time is not recommended, but
>  it has it place.
> >>>
> >>>
> >>> What places does it have?
> >>> I remain unconvinced that `in` has significant enough use cases to
> >>> warrant high-level ergonomics
> >>> were it being proposed today.
> >>>
> >>> It exists, and it'll probably never be removed from the language, but I
> >>> don't think it should be taught
> >>> as a good part of the language, and linters should probably flag it.
> >>
> >>
> >> Maybe a radical thought, but does this not apply to hasOwnProperty? If
> you
> >> have strong type management why test for a property? The one case I can
> >> think of is parsing JSON but I handle that with destructuring. Are there
> >> significant use cases for it? Should linters flag it?
> >
> >
> > Good questions.
> > Linters should flag
> >x.hasOwnProperty(y)
> > since if you're unsure whether x has an own property y you're probably
> > unsure whether x has an own property 'hasOwnProperty'.
> >
> > IIRC, destructuring traverses prototypes so see caveat about library code
> > and monkeypatching below.
> > const { toString: f } = {}
> > typeof f // 'funciton'
> >
> > You're right that in the middle of an application an instance's type
> should
> > determine whether a property is present.
> > There are use cases at the periphery.
> >
> > Use cases in bleeding edge JS include
> > * As you noted, operations on parsed JSON.  Even if you use revivers to
> > parse JSON to Maps instead of Objects
> >   you either need own property checks or Object.setPrototypeOf(parsed,
> null)
> > when populating the Map.
> > * Non-clobbering mass assignment.  Like Object.assign but that doesn't
> > overwrite existing properties in the assignee.
> > * Reliable hole detection in arrays: (1 !on [0, , 2])
> > * Adapters that use naming conventions between JS objects and external
> > systems, like between database field names and JS property names.
> > * Distinguishing between user-code-defined properties on a host object
> like
> > an HTML element and readonly host properties.
> >
> > Many use cases for hasOwnProperty could be better supported by Map, Set,
> and
> > Object.create(null) including:
> > * Objects used as lookup tables.
> > * Lookup tables with special purpose fallback logic like message bundles
> > that 

Re: Re: [proposal] Persistent variables in functions/methods

[Jacob Pratt]

> If it “belongs” inside a function, then it should “live” inside function
body `{ }`

Agreed, but these values don't live _inside_ the function, but rather
_alongside_ the function. If it were inside, it would share the lifetime
with the function call (which it doesn't).


jhpratt

On Tue, Jul 17, 2018 at 1:14 AM, Neek Sandhu 
wrote:

> It’d work but won’t be beautiful. With this proposal, code would be much
> easier to reason about.
>
>
>
> Also it breaks encapsulation (logical, semantic and syntactic), stuff
> should live where it belongs. If it “belongs” inside a function, then it
> should “live” inside function body `{ }`
>
>
>
> In the same context, notice how we evolved from callbacks to Promises and
> now to async/await shorthands.
>
>
>
> ```javascript
>
> const res = await fetch('http://example.com')
>
> ```
>
>
>
> More pretty than
>
>
>
> ```javascript
>
> fetch('http://example.com')
>
> .then(res => /* impl */)
>
> ```
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [proposal] Persistent variables in functions/methods

[Jacob Pratt]

Can you explain the difference between this and static properties? At quick
glance, I don't see any.

Would this not work?

```javascript
function foo(n) {
this.counter++;
return n * a;
}
foo.counter = 0;
foo.httpRE = /^https?/;
```


jhpratt

On Tue, Jul 17, 2018 at 12:56 AM, Neek Sandhu 
wrote:

> It'd be really useful to have variables inside methods/functions that are
> initialized once, reused for subsequent calls and live as long as
> containing scope i.e the function itself.
>
> > not to be confused with `static` properties
>
> ## Use Cases
>
> Almost every app has a function or method that needs to "preserve" some
> state across multiple calls, a counter for example. Current ways out of
> this situation are either closures created with IIFE's or making those
> variables top-level. Both of which are ugly. I think the same could be done
> much more neatly with persistent variables.
>
> ## Example
>
> ```javascript
> function foo(n) {
> // initialized on first call to foo, persists for subsequent calls
> persist let counter =  0;
>
> // this way JS engine won't have to recompile the pattern everytime
> persist const httpRE = /^https?/;
>
> counter++;
> return n * a;
> }
> ```
>
> is 1:1 as
>
> ```javascript
> let foo = (() => {
> let counter = 0;
> const httpRE = /^https?/;
> return (n) => {
> counter++;
> return  n * a;
> }
> })()
> ```
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional assignment operator

[Jacob Pratt]

This idea isn't quite the same as ||=, as that includes any falsey value,
nor ??=, as that includes null. My thought was to be able to set a property
if there is a value that exists (which would include null, but not
undefined).

It's certainly similar — should this be considered for addition to that
existing proposal?

My thinking was along the lines of "Set this if there is something to set.
If not, just keep going". It can be done with an if statement, but would
require a temporary reference due to getters and/or method calls.

jhpratt

On Thu, Jul 5, 2018 at 3:08 AM, Isiah Meadows 
wrote:

> How about you all take a look here:
> https://github.com/tc39/proposal-logical-assignment
>
> Originally, it was at
> <https://github.com/tc39/proposal-nullish-coalescing>, but here
> <https://github.com/tc39/proposal-nullish-coalescing/issues/1>, it was
> discussed and pushed off to the logical assignment proposal as it was
> also a short-circuiting operator, even though it wasn't really a
> *boolean* operator.
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Wed, Jul 4, 2018 at 10:25 PM, Sam Ruby  wrote:
> > On Wed, Jul 4, 2018 at 7:12 PM, Jacob Pratt 
> wrote:
> >> I've been having this thought recently, after running across a
> potential use
> >> case in practice. There will likely be conditional accessors at some
> point
> >> in the future (with optional chaining), but there will not be
> conditional
> >> assignment.
> >>
> >> My thought was to have the following:
> >> this.foo ?= params?.foo;
> >> which can be desugared to
> >> if (($ref = params?.foo) !== undefined) { this.foo = $ref; }
> >>
> >> I would strictly check for undefined, rather than nullish, as anything
> other
> >> than undefined would indicate that a value is present that can be set.
> If no
> >> value is present (such as a missing key on an object), nothing would be
> set.
> >> A reference must be used for the general case, as the object being
> assigned
> >> (the RHS) could be a function or getter with side-effects.
> >>
> >> Not sure if it should be ?= or =?, as it would look somewhat odd (IMO)
> for
> >> things like ?+= or +=?.
> >>
> >> Initial thoughts?
> >
> > Perl and Ruby have "||=" and "&&=" operators.  They don't strictly
> > check for undefined in either language.
> >
> > These operators are frequently used (in particular, "||=").  I do miss
> them.
> >
> > Looking at the node.js source:
> >
> > $ find . -name '*.js' -type f | xargs egrep ' (\S+) = \1 \|\| ' | wc -l
> >1416
> >
> > $ find . -name '*.js' -type f | xargs egrep ' if \(!(\S+)\) \1 = ' | wc
> -l
> >  497
> >
> > Nearly 2K occurrences in one code base.
> >
> >> Jacob Pratt
> >
> > - Sam Ruby
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Optional assignment operator

[Jacob Pratt]

I _personally_ have not found that to be a source of problems in this
instance, though I do on occasion have side effects in setters, such as
saving into a database, emitting data on a WebSocket instance, etc. They
could be debounced, but that's not always a feasible option.

I'd be interested to hear what others have to say about this proposal, as
this is (in all honesty) just something I came across and thought there
might be a better solution. The alternative you proposed, though not
identical, would work in the majority of cases. At least to me, it wasn't
immediately clear what it does when looking at it. Of course I fully
understand it, it's just something that might need a comment to explain.

jhpratt

On Wed, Jul 4, 2018 at 8:50 PM, Darien Valentine 
wrote:

> True — though I’m not sure why concern for this case would merit new
> syntax. Have you found that to be a common source of problems? Usually
> setters are light / idempotent.
>
> (Not opposed to the premise btw — just trying to hear more about what
> problems it would solve, especially since syntactic solutions usually have
> to be pretty high-value or else address something which can’t be  solved
> any other way.)
>
> On Wed, Jul 4, 2018 at 8:41 PM Jacob Pratt  wrote:
>
>> Sure, you'd be making an assignment no matter what in that case, which
>> would unnecessarily trigger the setter, possibly causing side effects.
>>
>> ```
>> const obj = {
>>   get x() {
>> return _x;
>>   },
>>
>>   set x(value) {
>> console.log('setter called');
>> _x = value;
>>   },
>>
>>   demo(params = {}) {
>> ({ x: this.x = this.x } = params);
>>   },
>> };
>>
>> obj.demo({ x: 5 });
>> obj.demo({ x: undefined });
>> ```
>>
>> This will log twice, where it only needs to trigger it once.
>>
>> jhpratt
>>
>> On Wed, Jul 4, 2018 at 8:16 PM, Darien Valentine 
>> wrote:
>>
>>> > My thought was to have the following: this.foo ?= params?.foo; which
>>> can be desugared to if (($ref = params?.foo) !== undefined) { this.foo =
>>> $ref; }
>>>
>>> Are there any specific advantages to the new syntax you’re describing?
>>> Initially, it appears to me like a less powerful form of an existing
>>> syntactic feature — default initializers and binding patterns allow
>>> expressing the same logic:
>>>
>>> ```
>>> const obj = {
>>>   demo(params={}) {
>>> ({ foo: this.foo=this.foo } = params);
>>>
>>> console.log(
>>>   `params was ${ JSON.stringify(params) }; ` +
>>>   `this.foo is now ${ JSON.stringify(this.foo) }`
>>> );
>>>   }
>>> }
>>>
>>> obj.demo({ foo: 1 });
>>> obj.demo({})
>>> obj.demo({ foo: 2 });
>>> obj.demo();
>>> obj.demo({ foo: 3 });
>>> obj.demo({});
>>> ```
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Optional assignment operator

[Jacob Pratt]

Sure, you'd be making an assignment no matter what in that case, which
would unnecessarily trigger the setter, possibly causing side effects.

```
const obj = {
  get x() {
return _x;
  },

  set x(value) {
console.log('setter called');
_x = value;
  },

  demo(params = {}) {
({ x: this.x = this.x } = params);
  },
};

obj.demo({ x: 5 });
obj.demo({ x: undefined });
```

This will log twice, where it only needs to trigger it once.

jhpratt

On Wed, Jul 4, 2018 at 8:16 PM, Darien Valentine 
wrote:

> > My thought was to have the following: this.foo ?= params?.foo; which can
> be desugared to if (($ref = params?.foo) !== undefined) { this.foo = $ref; }
>
> Are there any specific advantages to the new syntax you’re describing?
> Initially, it appears to me like a less powerful form of an existing
> syntactic feature — default initializers and binding patterns allow
> expressing the same logic:
>
> ```
> const obj = {
>   demo(params={}) {
> ({ foo: this.foo=this.foo } = params);
>
> console.log(
>   `params was ${ JSON.stringify(params) }; ` +
>   `this.foo is now ${ JSON.stringify(this.foo) }`
> );
>   }
> }
>
> obj.demo({ foo: 1 });
> obj.demo({})
> obj.demo({ foo: 2 });
> obj.demo();
> obj.demo({ foo: 3 });
> obj.demo({});
> ```
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Optional assignment operator

[Jacob Pratt]

I've been having this thought recently, after running across a potential
use case in practice. There will likely be conditional accessors at some
point in the future (with optional chaining), but there will not be
conditional assignment.

My thought was to have the following:
this.foo ?= params?.foo;
which can be desugared to
if (($ref = params?.foo) !== undefined) { this.foo = $ref; }

I would strictly check for undefined, rather than nullish, as anything
other than undefined would indicate that a value is present that can be
set. If no value is present (such as a missing key on an object), nothing
would be set. A reference must be used for the general case, as the object
being assigned (the RHS) could be a function or getter with side-effects.

Not sure if it should be ?= or =?, as it would look somewhat odd (IMO) for
things like ?+= or +=?.

Initial thoughts?
Jacob Pratt
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: withBreak blocks

[Jacob Pratt]

Can you provide a clear use case that can't (or shouldn't) be covered by
what others have mentioned?

jhpratt

On Sat, Feb 17, 2018 at 4:23 PM, sagiv ben giat 
wrote:

> That's not what i'm looking for.
> I may want to do some more things inside the function besides validations.
>
> Sagiv b.g
>
> On Sat, Feb 17, 2018 at 11:19 PM, Peter Jaszkowiak 
> wrote:
>
>> Also, you can just use `return` if you're in a function:
>>
>> ```
>> const doWork = () => {
>>   // try catch omitted for brevity
>>   const response = fetchData();
>>
>>   if (response.error) {
>> log(response.message);
>> return;
>>   }
>>   if (!response.data) {
>> log("No data");
>> return;
>>   }
>>   if (!response.data.todos) {
>> log("No Todos");
>> return;
>>   }
>>
>>   return action({ data: response.data });
>> };
>> ```
>>
>> On Sat, Feb 17, 2018 at 2:17 PM, Oriol _ 
>> wrote:
>>
>>> This is so close to your proposal, and already works right now:
>>>
>>> ```js
>>> block: {
>>>   if (response.error) {
>>> log(response.message);
>>> break block;
>>>   }
>>>   if (!response.data) {
>>> log("No data");
>>> break block;
>>>   }
>>>   if (!response.data.todos) {
>>> log("No Todos");
>>> break block;
>>>   }
>>>   return action({ data: response.data });
>>> }
>>> ```
>>>
>>> - Oriol
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: withBreak blocks

[Jacob Pratt]

Perhaps I'm missing something, but why wouldn't an `else if` work here?

jhpratt

On Sat, Feb 17, 2018 at 4:02 PM, sagiv ben giat 
wrote:

> I hope I'm on the right medium for this, I would like to propose a
> language feature.
> withBreak blocks
>
> Well the name might not be the best, but it's just my way to be the most
> clear about this feature proposal.
>
> I often find my self doing this in my code:
>
> const doWork = () => {
>   // try catch omitted for brevity
>   const response = fetchData();
>   do {
> if (response.error) {
>   log(response.message);
>   break;
> }
> if (!response.data) {
>   log("No data");
>   break;
> }
> if (!response.data.todos) {
>   log("No Todos");
>   break;
> }
> return action({ data: response.data });
>   } while (false);
> };
>
> I'm doing this instead of doing bunch of  if / else if / else blocks or
> ugly nested if blocks.
>  What i would like to have is a block that will let me break without being
> in a loop context.
> Something like this:
> withBreak {
>   if (response.error) {
> log(response.message);
> break;
>   }
>   if (!response.data) {
> log("No data");
> break;
>   }
>   if (!response.data.todos) {
> log("No Todos");
> break;
>   }
>   return action({ data: response.data });
> }
>
> This can be a synthetic sugar for do{}while(false)  behind the scenes.
>
> Best regards,
>
> Sagiv B.G
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss