Re: nits on BigInt Proposal

[kai zhu]

> On Feb 10, 2018, at 12:26 AM, Isiah Meadows  wrote:
> 
> Kai, mind commenting about this in the proposal's repo (filing a new issue 
> there), where you'll more likely get feedback?
> 
yea, and got feedback. turns out there’s a serious footgun [1] using 
string-only interface :(

[1] https://github.com/tc39/proposal-bigint/issues/120#issuecomment-364521444 

> 
> On Fri, Feb 9, 2018, 08:51 kai zhu  > wrote:
> @bruno, i'm wondering if having a DecimalFloat128Array (based on ieee 754 
> standard) is good enough for accounting (with 34 decimal-digit precision)?  
> like existing database drivers, you can only get/set strings, but infix / 
> inplace operators wouldn’t have that restriction.
> 
> e.g.:
> ```javascript
> aa = new DecimalFloat128Array(['9823749.82742']);
> // aa[0] can only be exposed as the string '9823749.82742'
> console.assert(typeof aa[0] === 'string' && aa[0] === '9823749.82742');
> // aa[0] can only be set using string as well
> aa[0] = '87834398978.798';
> 
> aa = new DecimalFloat128Array(['.1']);
> bb = new DecimalFloat128Array(['3']);
> // cc is assigned the string '0.3',
> // but the engines should be able to easily optimize hotspots that use infix 
> and inplace operators
> // with native-types,
> // if implicit coercion is disallowed between DecimalFloat128Array and other 
> types.
> cc = aa[0] * bb[0];
> aa[0] *= bb[0];
> 
> // guidance for database drivers would be to implement string get/set as well
> aa = new DecimalFloat128Array(['97324927.8934723'])
> mysqlDriver.execute(
> 'INSERT INTO mydecimaltable (?,?,?);',
> ['id1234', aa[0],'foo'],
> function (error) {
> mysqlDriver.execute(
> 'SELECT decimalValue,foo FROM mydecimaltable WHERE id=id1234;',
> function (error, valueList) {
> // db-driver exposes valueList[0] as the string 
> '97324927.8934723'
> console.assert(typeof valueList[0] === 'string' && 
> valueList[0] === '97324927.8934723');
> }
> );
> }
> );
> ```
> 
> 
> pros:
> - requires no new language-syntax
> - avoids introducing new typeof's to the javascript-language, which avoids 
> compatibility-risks with existing database drivers (use strings to get/set 
> values)
> 
> cons:
> - arithmetic for scalars is weird: aa[0] + bb[0] (instead of aa + bb)
> - does not support arbitrary precision (but are there common javascript 
> use-cases requiring arbitrary precision?)
> 
> 
>> On Aug 4, 2017, at 10:42 PM, Bruno Jouhier > > wrote:
>> 
>> BigDecimal is a MUST for accounting.
>> 
>> Main reasons:
>> JS number precision is too limited (16 digits) 
>> Decimal numbers are not represented "exactly" by JS numbers => comparisons 
>> gives surprising results (0.1 + 0.2 !== 0.3).
>> Incorrect roundtrips with SQL Databases: decimals have up to 38 digits 
>> precision in Oracle and SQL Server, 65 (!!) in MySQL.
>> JSON serialization is addressed by serializing to string. Like dates (no 
>> date literals in JS/JSON).
>> 
>> Same for SQL. In the absence of a BigDecimal type on JS side, values are 
>> passed as strings.
>> 
>> Bruno
>> 
>> 
>> 
>> 
>> ___
>> 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: Suggestion: Destructuring object initializer.

[Bob Myers]

Thank you for your comments.

The proposed picking syntax has gone through several iterations. Way back
when, we had

```
o # {a, b}
```

for picking properties `a` and `b` from `o`, resulting in `{a: o.a, b:
o.b}`. That, however, would of course eat a precious symbol. So a later
version replaced the `#` with the dot `.`, which makes some semantic sense,
since the dot has been used for two decades to "pick" a property into a
*value*; that is the reason that in some versions this proposal was called
"extended dot notation". This looked like:

```
o.{a, b}
```

This proposal had the benefit of a narrow syntactic footprint, since the
grammar has never allowed anything other than an identifier to follow the
dot. On the other hand, it had the downside that the dot was not very
visible.

(I unfortunately then muddied the waters by trying to extend the dot in
additional ways, such as bracket-less array indices, finally solving the
`array#first` and `array#last` problems by allowing `array.0` and
`array.-1`. But I digress.)

But then I considered that we might want to pick from two or more objects
into a single new object, and I didn't see how to do that easily with this
syntax. But now we have spread properties, so we could write

```
{...p.{p1, p2}, ...q.{q1, q2}}
```

But there was another consideration, which was consistency of syntax
between picking (destructuring) into variables, versus picking into
objects. Since ES6 we have had the `{p2, p2} = p` syntax for picking into
variables. So the notion was to use precisely this destructuring assignment
syntax, complete with its features for defaults, renaming, and nesting, for
picking into objects, simply by placing it inside an object literal. That's
how I ended up with the current proposal, which is

```
{ {p1, p2} = p, {q1, q2} = q }
```

But I still think the so-called "extended dot notation" version is entirely
viable.

Looking back over some old threads, I see comments like:

> The first issue (in chronological order) with that proposal is the lack
of motivation. What is the problem that the proposal is trying to solve?

Whatever one can say about this problem or proposed solution does not
include it not being well-defined. The problem statement is that we want to
pick properties `p1`, `p2`, and `p3` from one object `p` into another
object, in a more concise, brief, less repetitive, less error-prone way
than saying `{p1: p.p1, p2: p.p2, p3: p.p3}`. I wonder if that is really
that hard to understand. Whether or not that's *important* is a different
question, of course.

The reason I started thinking about this issue, eons ago, is that I ran
into it, regularly, in my own programming work, since I'm an active
programmer who designs and codes much of the day. This question of how to
"pick" from objects into objects also comes up over and over again on Stack
Overflow. The current "best" "one-line" solution, at least by number of
upvotes (provided by me, before I went cold turkey) was

```
(({p1, p2}) => ({p1, p2}))(p)
```

This requirement/need/desire has also been raised on this forum half a
dozen times by different folks over the years.

Of all the reactions to this proposal, other than "who cares", one of the
most common is that we already have `_.pick` in popular libraries. Well,
something being in a library can just as easily be interpreted as meaning
it's a *good* candidate for being added to the language, as meaning that it
doesn't need to be. Also, implementing this in user-land also requires
quoting the property names, as in `_.pick(p, ['p1', 'p2'])`, which is
awkward at best. New features in Typescript allow you to write your own
pick-type operators in a more type-safe way than was the case previously,
but still it requires some gymnastics.

Another common reaction is "big deal, saving a few characters or lines".
But more than one recent language feature also falls into this category of
mainly or purely sugar and brevity. For instance, property spread syntax is
pretty much just sugar for `Object.assign`, yet everyone seems to think
it's the best thing since sliced bread.

Bob

On Sat, Feb 10, 2018 at 10:07 AM, Naveen Chawla 
wrote:

> Sorry sent by accident before my message was edited properly. My basic
> point was that since curly braces are used for both destructuring and
> object literals, there's an issue with being able to glance at the code and
> quickly discern what's happening if they are mixed together in the same
> piece of syntax. Not impossible, just a potential source of bugs and/or
> delay in understanding the data structure being declared.
>
> On Sat, 10 Feb 2018 at 10:01 Naveen Chawla  wrote:
>
>> I'm not a TC39 member, but I have a little readability issue with
>> destructuring inside an object:
>>
>> ```js
>> { {p1, p2} = p, {q1, q2} = q }
>> ```
>>
>> has a very different meaning than
>>
>> ```js
>> { p: {p1, p2}, {q1, q2} = q }
>> ```
>>
>
___

Proposal: deleting properties in object initializer expression

[Douglas Meyer]

With spread properties, it would be great to be able to remove specific
properties:
```js
const obj1 = { one: 1, two: 2, three: 3 };
const obj2 = {
...obj1,
delete three // <-- new syntax
};
```

`obj2` would be `{ one: 1, two: 2 }`. This syntax is visually similar to
the getter/setter syntax. This should also support the computed property
approach:
```js
const propName="three";
const obj1 = { one: 1, two: 2, [propName]: 3 };
const obj2 = { ...obj1, delete [propName] };
```

There are 2 ways of currently doing this:
```js
const { three, ...obj2 } = obj1; // has the side-effect of creating
unnecessary variable `three`.
delete obj2.three; // seems odd to create an object to then reach-in and
remove things.
```
It is worth noting that `const obj2 = { ...obj1, three: undefined }` is not
the same thing, as `obj2.hasOwnProperty('three')` would still return true.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Destructuring object initializer.

[Naveen Chawla]

Sorry sent by accident before my message was edited properly. My basic
point was that since curly braces are used for both destructuring and
object literals, there's an issue with being able to glance at the code and
quickly discern what's happening if they are mixed together in the same
piece of syntax. Not impossible, just a potential source of bugs and/or
delay in understanding the data structure being declared.

On Sat, 10 Feb 2018 at 10:01 Naveen Chawla  wrote:

> I'm not a TC39 member, but I have a little readability issue with
> destructuring inside an object:
>
> ```js
> { {p1, p2} = p, {q1, q2} = q }
> ```
>
> has a very different meaning than
>
> ```js
> { p: {p1, p2}, {q1, q2} = q }
> ```
>
>
> On Fri, 9 Feb 2018 at 16:55 Bob Myers  wrote:
>
>> Thanks for your input.
>>
>> Actually, I was not trying to beat the dead horse of my property picking
>> proposal, but rather give advice to another would-be spec proposer based on
>> my experience.
>>
>> But since you brought it up, the spec for property picking can be found
>> at https://github.com/rtm/js-pick-notation. As with any spec, one could
>> argue that it's too brief, or too verbose, or missing this or that, but
>> actually this is a very simple feature. There is a fair amount of
>> discussion on this list about this proposal, in various iterations, over
>> the last few years.
>>
>> As for an implementation, the TC39 process documents clearly state that
>> the implementation types expected for Stage 0 (strawman) is "*N/A*". I'd
>> be glad to write a Babel or sweet.js implementation, but I'm not quite sure
>> what it would prove.
>>
>> Although the TC39 documents are murky on this point, and some of them
>> appear to state that a proposal can gain Stage 0 status without a champion,
>> other information seems to say that getting a proposal to Stage 0 DOES
>> require the involvement of a TC39 member, even if they are not technically
>> considered a "champion" at that point...As for "trying to find" such a
>> champion, I thought posting to this group constituted such an effort, and
>> in addition I have reached out to a couple of members with no response.
>>
>> Here's a real quick intro to the proposal:
>>
>> ```
>> const {p1, p2} = p;
>> const [q1, q2} = q;
>> return {p1, p2, q2, q2};
>>
>> ==or==
>>
>> return {p1: p.p1, p2: p.p2, q1:q.q1, p2: q.q2};
>> ```
>>
>> becomes
>>
>> ```
>> return { {p1, p2} = p, {q1, q2} = q };
>> ```
>>
>> Yes, it's pretty much sugar--no brand new functionality here. It's about
>> brevity and expressiveness, which seems to have been a low enough bar for
>> several other features to pass. It steals no new symbols. It clearly
>> leverages existing destructuring assignment syntactical infrastructure.
>>
>> Bob
>>
>> On Fri, Feb 9, 2018 at 4:25 PM, Andy Earnshaw 
>> wrote:
>>
>>> Bob, I think it's an interesting idea too, but you can't strong-arm
>>> people into getting excited about what you're asking for.  If it really is
>>> that important to you then put together a solid proposal, write a Babel
>>> plugin and then try to find a champion for it.
>>>
>>> On Thu, 8 Feb 2018 at 14:05 Bob Myers  wrote:
>>>
 It does make one stop and wonder why the group will endlessly entertain
 trolls debating whether or not ES6 (or ES5) portends the end of
 civilization as we know it, while relentlessly ignoring literally dozens of
 similar/identical proposals for property picking, a feature which easily
 contributes as much to the language at as little cost as many other
 features such as spread properties.

>>> ___
>> 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: Suggestion: Destructuring object initializer.

[Naveen Chawla]

I'm not a TC39 member, but I have a little readability issue with
destructuring inside an object:

```js
{ {p1, p2} = p, {q1, q2} = q }
```

has a very different meaning than

```js
{ p: {p1, p2}, {q1, q2} = q }
```


On Fri, 9 Feb 2018 at 16:55 Bob Myers  wrote:

> Thanks for your input.
>
> Actually, I was not trying to beat the dead horse of my property picking
> proposal, but rather give advice to another would-be spec proposer based on
> my experience.
>
> But since you brought it up, the spec for property picking can be found at
> https://github.com/rtm/js-pick-notation. As with any spec, one could
> argue that it's too brief, or too verbose, or missing this or that, but
> actually this is a very simple feature. There is a fair amount of
> discussion on this list about this proposal, in various iterations, over
> the last few years.
>
> As for an implementation, the TC39 process documents clearly state that
> the implementation types expected for Stage 0 (strawman) is "*N/A*". I'd
> be glad to write a Babel or sweet.js implementation, but I'm not quite sure
> what it would prove.
>
> Although the TC39 documents are murky on this point, and some of them
> appear to state that a proposal can gain Stage 0 status without a champion,
> other information seems to say that getting a proposal to Stage 0 DOES
> require the involvement of a TC39 member, even if they are not technically
> considered a "champion" at that point...As for "trying to find" such a
> champion, I thought posting to this group constituted such an effort, and
> in addition I have reached out to a couple of members with no response.
>
> Here's a real quick intro to the proposal:
>
> ```
> const {p1, p2} = p;
> const [q1, q2} = q;
> return {p1, p2, q2, q2};
>
> ==or==
>
> return {p1: p.p1, p2: p.p2, q1:q.q1, p2: q.q2};
> ```
>
> becomes
>
> ```
> return { {p1, p2} = p, {q1, q2} = q };
> ```
>
> Yes, it's pretty much sugar--no brand new functionality here. It's about
> brevity and expressiveness, which seems to have been a low enough bar for
> several other features to pass. It steals no new symbols. It clearly
> leverages existing destructuring assignment syntactical infrastructure.
>
> Bob
>
> On Fri, Feb 9, 2018 at 4:25 PM, Andy Earnshaw 
> wrote:
>
>> Bob, I think it's an interesting idea too, but you can't strong-arm
>> people into getting excited about what you're asking for.  If it really is
>> that important to you then put together a solid proposal, write a Babel
>> plugin and then try to find a champion for it.
>>
>> On Thu, 8 Feb 2018 at 14:05 Bob Myers  wrote:
>>
>>> It does make one stop and wonder why the group will endlessly entertain
>>> trolls debating whether or not ES6 (or ES5) portends the end of
>>> civilization as we know it, while relentlessly ignoring literally dozens of
>>> similar/identical proposals for property picking, a feature which easily
>>> contributes as much to the language at as little cost as many other
>>> features such as spread properties.
>>>
>> ___
> 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: try/catch/else

[Alan Plum]

The idea isn't to make the second call's exceptions silent, it's not to catch them (i.e. let them propagate).On 9 Feb 2018 2:46 p.m., Augusto Moura  wrote:I see this operator quite confusing, in my opinion it's a best practice treat the functions (and errors) separately. If you want to ignore the second error you can even create a `silent` helper.```jsconst treatedShowSuggestions = (suggs) => {  try {    showSuggestions(suggs);  } catch (e) {    // treat error};try {  const suggestions = await fetchSuggestions();  treatedShowSuggestions(suggestions);} catch (e) {  alert('Failed to load suggestions');}```or```jsconst silent = (fn) => {  try {    fn();  } catch (e) {}};try {  const suggestions = await fetchSuggestions();  silent(() => showSuggestions(suggestions));} catch (e) {  alert('Failed to load suggestions');}```This isn't even a workaround, it's just the right approach for what you want. If you wanna to evict the separated functions you can just inline the try/catch in the main function.-- Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: nits on BigInt Proposal

[Isiah Meadows]

Kai, mind commenting about this in the proposal's repo (filing a new issue
there), where you'll more likely get feedback?

On Fri, Feb 9, 2018, 08:51 kai zhu  wrote:

> @bruno, i'm wondering if having a DecimalFloat128Array (based on ieee 754
> standard) is good enough for accounting (with 34 decimal-digit precision)?
>  like existing database drivers, you can only get/set strings, but infix /
> inplace operators wouldn’t have that restriction.
>
> e.g.:
> ```javascript
> aa = new DecimalFloat128Array(['9823749.82742']);
> // aa[0] can only be exposed as the string '9823749.82742'
> console.assert(typeof aa[0] === 'string' && aa[0] === '9823749.82742');
> // aa[0] can only be set using string as well
> aa[0] = '87834398978.798';
>
> aa = new DecimalFloat128Array(['.1']);
> bb = new DecimalFloat128Array(['3']);
> // cc is assigned the string '0.3',
> // but the engines should be able to easily optimize hotspots that use
> infix and inplace operators
> // with native-types,
> // if implicit coercion is disallowed between DecimalFloat128Array and
> other types.
> cc = aa[0] * bb[0];
> aa[0] *= bb[0];
>
> // guidance for database drivers would be to implement string get/set as
> well
> aa = new DecimalFloat128Array(['97324927.8934723'])
> mysqlDriver.execute(
> 'INSERT INTO mydecimaltable (?,?,?);',
> ['id1234', aa[0],'foo'],
> function (error) {
> mysqlDriver.execute(
> 'SELECT decimalValue,foo FROM mydecimaltable WHERE id=id1234;',
> function (error, valueList) {
> // db-driver exposes valueList[0] as the string
> '97324927.8934723'
> console.assert(typeof valueList[0] === 'string' &&
> valueList[0] === '97324927.8934723');
> }
> );
> }
> );
> ```
>
>
> pros:
> - requires no new language-syntax
> - avoids introducing new typeof's to the javascript-language, which avoids
> compatibility-risks with existing database drivers (use strings to get/set
> values)
>
> cons:
> - arithmetic for scalars is weird: aa[0] + bb[0] (instead of aa + bb)
> - does not support arbitrary precision (but are there common javascript
> use-cases requiring arbitrary precision?)
>
>
> On Aug 4, 2017, at 10:42 PM, Bruno Jouhier  wrote:
>
> BigDecimal is a MUST for accounting.
>
> Main reasons:
>
>- JS number precision is too limited (16 digits)
>- Decimal numbers are not represented "exactly" by JS numbers =>
>comparisons gives surprising results (0.1 + 0.2 !== 0.3).
>- Incorrect roundtrips with SQL Databases: decimals have up to 38
>digits precision in Oracle and SQL Server, 65 (!!) in MySQL.
>
> JSON serialization is addressed by serializing to string. Like dates (no
> date literals in JS/JSON).
>
> Same for SQL. In the absence of a BigDecimal type on JS side, values are
> passed as strings.
>
> Bruno
>
>
>
>
> ___
> 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: Cloning WeakSet/WeakMap

[Michał Wadas]

Why would they? You can put single object in *infinite* amount of WeakSets
and it won't prevent it's garbage collection.

On 9 Feb 2018 4:11 pm, "Michael Luder-Rosefield" 
wrote:

> Possibly a silly question, but...
>
> What happens re garbage collection if you have two WeakSets referencing
> the same object? Do they each block that object's removal?
>
> On Fri, 9 Feb 2018 at 15:05 Michał Wadas  wrote:
>
>> English isn't my native language, so I probably made a mistake.
>>
>> I was asked to add WeakSet.prototype.union(iterable) creating new
>> WeakSet instance including data from both iterable and original WeakSet.
>>
>>
>>
>> On 9 Feb 2018 4:01 pm, "David Bruant"  wrote:
>>
>>> Hi,
>>>
>>> My understanding is that cloning a WeakSet into a Set would remove all
>>> its properties related to security and garbage collection.
>>>
>>> The properties related to security and garbage collection of WeakSet are
>>> based on the fact that its elements are not enumerable by someone who would
>>> only be holding a reference to the WeakSet. If you want to "clone" a
>>> WeakSet into a Set it means you have an expectation that the set of
>>> elements are deterministically enumerable.
>>>
>>> WeakSets and Sets, despite there close name and API, are used in
>>> different circumstances.
>>>
>>> David
>>>
>>>
>>> 2018-02-09 9:53 GMT-05:00 Michał Wadas :
>>>
 Hi.

 I was asked to include a way to clone WeakSet in Set builtins proposal.
 Is there any consensus on security of such operation?

 Michał Wadas

 ___
 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: Cloning WeakSet/WeakMap

[David Bruant]

2018-02-09 10:05 GMT-05:00 Michał Wadas :

> English isn't my native language, so I probably made a mistake.
>
oh ok, sorry for my misinterpretation


> I was asked to add WeakSet.prototype.union(iterable) creating new WeakSet
> instance including data from both iterable and original WeakSet.
>
ok, I don't have an opinion on this idea

David


>
>
>
> On 9 Feb 2018 4:01 pm, "David Bruant"  wrote:
>
>> Hi,
>>
>> My understanding is that cloning a WeakSet into a Set would remove all
>> its properties related to security and garbage collection.
>>
>> The properties related to security and garbage collection of WeakSet are
>> based on the fact that its elements are not enumerable by someone who would
>> only be holding a reference to the WeakSet. If you want to "clone" a
>> WeakSet into a Set it means you have an expectation that the set of
>> elements are deterministically enumerable.
>>
>> WeakSets and Sets, despite there close name and API, are used in
>> different circumstances.
>>
>> David
>>
>>
>> 2018-02-09 9:53 GMT-05:00 Michał Wadas :
>>
>>> Hi.
>>>
>>> I was asked to include a way to clone WeakSet in Set builtins proposal.
>>> Is there any consensus on security of such operation?
>>>
>>> Michał Wadas
>>>
>>> ___
>>> 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: Cloning WeakSet/WeakMap

[Michał Wadas]

English isn't my native language, so I probably made a mistake.

I was asked to add WeakSet.prototype.union(iterable) creating new WeakSet
instance including data from both iterable and original WeakSet.



On 9 Feb 2018 4:01 pm, "David Bruant"  wrote:

> Hi,
>
> My understanding is that cloning a WeakSet into a Set would remove all its
> properties related to security and garbage collection.
>
> The properties related to security and garbage collection of WeakSet are
> based on the fact that its elements are not enumerable by someone who would
> only be holding a reference to the WeakSet. If you want to "clone" a
> WeakSet into a Set it means you have an expectation that the set of
> elements are deterministically enumerable.
>
> WeakSets and Sets, despite there close name and API, are used in different
> circumstances.
>
> David
>
>
> 2018-02-09 9:53 GMT-05:00 Michał Wadas :
>
>> Hi.
>>
>> I was asked to include a way to clone WeakSet in Set builtins proposal.
>> Is there any consensus on security of such operation?
>>
>> Michał Wadas
>>
>> ___
>> 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: Cloning WeakSet/WeakMap

[Thomas Grainger]

I think this is referring to cloning a WeakSet into another WeakSet

Thomas Grainger

On 9 February 2018 at 15:01, David Bruant  wrote:

> Hi,
>
> My understanding is that cloning a WeakSet into a Set would remove all its
> properties related to security and garbage collection.
>
> The properties related to security and garbage collection of WeakSet are
> based on the fact that its elements are not enumerable by someone who would
> only be holding a reference to the WeakSet. If you want to "clone" a
> WeakSet into a Set it means you have an expectation that the set of
> elements are deterministically enumerable.
>
> WeakSets and Sets, despite there close name and API, are used in different
> circumstances.
>
> David
>
>
> 2018-02-09 9:53 GMT-05:00 Michał Wadas :
>
>> Hi.
>>
>> I was asked to include a way to clone WeakSet in Set builtins proposal.
>> Is there any consensus on security of such operation?
>>
>> Michał Wadas
>>
>> ___
>> 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: Cloning WeakSet/WeakMap

[David Bruant]

Hi,

My understanding is that cloning a WeakSet into a Set would remove all its
properties related to security and garbage collection.

The properties related to security and garbage collection of WeakSet are
based on the fact that its elements are not enumerable by someone who would
only be holding a reference to the WeakSet. If you want to "clone" a
WeakSet into a Set it means you have an expectation that the set of
elements are deterministically enumerable.

WeakSets and Sets, despite there close name and API, are used in different
circumstances.

David


2018-02-09 9:53 GMT-05:00 Michał Wadas :

> Hi.
>
> I was asked to include a way to clone WeakSet in Set builtins proposal. Is
> there any consensus on security of such operation?
>
> Michał Wadas
>
> ___
> 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

Cloning WeakSet/WeakMap

[Michał Wadas]

Hi.

I was asked to include a way to clone WeakSet in Set builtins proposal. Is
there any consensus on security of such operation?

Michał Wadas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: nits on BigInt Proposal

[kai zhu]

@bruno, i'm wondering if having a DecimalFloat128Array (based on ieee 754 
standard) is good enough for accounting (with 34 decimal-digit precision)?  
like existing database drivers, you can only get/set strings, but infix / 
inplace operators wouldn’t have that restriction.

e.g.:
```javascript
aa = new DecimalFloat128Array(['9823749.82742']);
// aa[0] can only be exposed as the string '9823749.82742'
console.assert(typeof aa[0] === 'string' && aa[0] === '9823749.82742');
// aa[0] can only be set using string as well
aa[0] = '87834398978.798';

aa = new DecimalFloat128Array(['.1']);
bb = new DecimalFloat128Array(['3']);
// cc is assigned the string '0.3',
// but the engines should be able to easily optimize hotspots that use infix 
and inplace operators
// with native-types,
// if implicit coercion is disallowed between DecimalFloat128Array and other 
types.
cc = aa[0] * bb[0];
aa[0] *= bb[0];

// guidance for database drivers would be to implement string get/set as well
aa = new DecimalFloat128Array(['97324927.8934723'])
mysqlDriver.execute(
'INSERT INTO mydecimaltable (?,?,?);',
['id1234', aa[0],'foo'],
function (error) {
mysqlDriver.execute(
'SELECT decimalValue,foo FROM mydecimaltable WHERE id=id1234;',
function (error, valueList) {
// db-driver exposes valueList[0] as the string 
'97324927.8934723'
console.assert(typeof valueList[0] === 'string' && valueList[0] 
=== '97324927.8934723');
}
);
}
);
```


pros:
- requires no new language-syntax
- avoids introducing new typeof's to the javascript-language, which avoids 
compatibility-risks with existing database drivers (use strings to get/set 
values)

cons:
- arithmetic for scalars is weird: aa[0] + bb[0] (instead of aa + bb)
- does not support arbitrary precision (but are there common javascript 
use-cases requiring arbitrary precision?)


> On Aug 4, 2017, at 10:42 PM, Bruno Jouhier  wrote:
> 
> BigDecimal is a MUST for accounting.
> 
> Main reasons:
> JS number precision is too limited (16 digits) 
> Decimal numbers are not represented "exactly" by JS numbers => comparisons 
> gives surprising results (0.1 + 0.2 !== 0.3).
> Incorrect roundtrips with SQL Databases: decimals have up to 38 digits 
> precision in Oracle and SQL Server, 65 (!!) in MySQL.
> JSON serialization is addressed by serializing to string. Like dates (no date 
> literals in JS/JSON).
> 
> Same for SQL. In the absence of a BigDecimal type on JS side, values are 
> passed as strings.
> 
> Bruno
> 
> 
> 
> 
> ___
> 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: try/catch/else

[Augusto Moura]

I see this operator quite confusing, in my opinion it's a best practice
treat the functions (and errors) separately. If you want to ignore the
second error you can even create a `silent` helper.

```js
const treatedShowSuggestions = (suggs) => {
  try {
showSuggestions(suggs);
  } catch (e) {
// treat error
};

try {
  const suggestions = await fetchSuggestions();
  treatedShowSuggestions(suggestions);
} catch (e) {
  alert('Failed to load suggestions');
}
```
or
```js
const silent = (fn) => {
  try {
fn();
  } catch (e) {}
};

try {
  const suggestions = await fetchSuggestions();
  silent(() => showSuggestions(suggestions));
} catch (e) {
  alert('Failed to load suggestions');
}
```

This isn't even a workaround, it's just the right approach for what you
want. If you wanna to evict the separated functions you can just inline the
try/catch in the main function.
-- 
Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Destructuring object initializer.

[Bob Myers]

Thanks for your input.

Actually, I was not trying to beat the dead horse of my property picking
proposal, but rather give advice to another would-be spec proposer based on
my experience.

But since you brought it up, the spec for property picking can be found at
https://github.com/rtm/js-pick-notation. As with any spec, one could argue
that it's too brief, or too verbose, or missing this or that, but actually
this is a very simple feature. There is a fair amount of discussion on this
list about this proposal, in various iterations, over the last few years.

As for an implementation, the TC39 process documents clearly state that the
implementation types expected for Stage 0 (strawman) is "*N/A*". I'd be
glad to write a Babel or sweet.js implementation, but I'm not quite sure
what it would prove.

Although the TC39 documents are murky on this point, and some of them
appear to state that a proposal can gain Stage 0 status without a champion,
other information seems to say that getting a proposal to Stage 0 DOES
require the involvement of a TC39 member, even if they are not technically
considered a "champion" at that point...As for "trying to find" such a
champion, I thought posting to this group constituted such an effort, and
in addition I have reached out to a couple of members with no response.

Here's a real quick intro to the proposal:

```
const {p1, p2} = p;
const [q1, q2} = q;
return {p1, p2, q2, q2};

==or==

return {p1: p.p1, p2: p.p2, q1:q.q1, p2: q.q2};
```

becomes

```
return { {p1, p2} = p, {q1, q2} = q };
```

Yes, it's pretty much sugar--no brand new functionality here. It's about
brevity and expressiveness, which seems to have been a low enough bar for
several other features to pass. It steals no new symbols. It clearly
leverages existing destructuring assignment syntactical infrastructure.

Bob

On Fri, Feb 9, 2018 at 4:25 PM, Andy Earnshaw 
wrote:

> Bob, I think it's an interesting idea too, but you can't strong-arm people
> into getting excited about what you're asking for.  If it really is that
> important to you then put together a solid proposal, write a Babel plugin
> and then try to find a champion for it.
>
> On Thu, 8 Feb 2018 at 14:05 Bob Myers  wrote:
>
>> It does make one stop and wonder why the group will endlessly entertain
>> trolls debating whether or not ES6 (or ES5) portends the end of
>> civilization as we know it, while relentlessly ignoring literally dozens of
>> similar/identical proposals for property picking, a feature which easily
>> contributes as much to the language at as little cost as many other
>> features such as spread properties.
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Destructuring object initializer.

[Andy Earnshaw]

Bob, I think it's an interesting idea too, but you can't strong-arm people
into getting excited about what you're asking for.  If it really is that
important to you then put together a solid proposal, write a Babel plugin
and then try to find a champion for it.

On Thu, 8 Feb 2018 at 14:05 Bob Myers  wrote:

> It does make one stop and wonder why the group will endlessly entertain
> trolls debating whether or not ES6 (or ES5) portends the end of
> civilization as we know it, while relentlessly ignoring literally dozens of
> similar/identical proposals for property picking, a feature which easily
> contributes as much to the language at as little cost as many other
> features such as spread properties.
>
> Bob
>
> On Thu, Feb 8, 2018 at 4:15 PM, Bob Myers  wrote:
>
>> This extremely useful feature, which is sometimes called "picking", has
>> been discussed extensively on the group, but the "thought leaders" (?) who
>> apparently have the ability to kill a feature by saying "I don't really
>> think it's that important" have failed to get excited about it, although it
>> seems to me to be at least as "interesting" (in terms of the unwritten
>> criteria apparently applied to determine "interesting") as many other
>> features which are progressing through the ES39 life-cycle, and the nature
>> of the TC39 governance process, which gives entirely new meaning to the
>> notion of "design by committee", makes it impossible to find the champion
>> which is the gating factor for the entire process.
>>
>> Bob
>>
>> On Thu, Feb 8, 2018 at 3:15 PM, Yeong-u Kim  wrote:
>>
>>> # Suggestion: Destructuring object initializer.
>>>
>>> --
>>>
>>>  Destructuring assignment: it extracts values by destructuring an
>>> object, and assign _them_ to ‘variables.’ I suggest Destructuring object
>>> initialization syntax; it is similar to Destructuring assignment, except
>>> that it initializes an object with _the extracted values_.
>>>
>>> ```javascript
>>> const name_info = {"first name": "Yeong-u", "last name": "Kim",
>>> nickname: "K."};
>>> const e = "computed property name";
>>>
>>> const object = {
>>> name: {
>>> *{"first name": forename, "last name": surname}: name_info
>>> },
>>> *[a, b, c]: [1, 2, 3],
>>> *[d]: [4],
>>> [e]: "This is not part of the syntax"
>>> *[{"some property name": "new one"}]: [{"some property name": 5}],
>>> *{gettable: something}: {get gettable() {return Symbol("Using
>>> [[Get]]");}}
>>> };
>>> /*
>>> {
>>> name: {
>>> forename: "Yeong-u",
>>> surname: "Kim"
>>> },
>>> a: 1,
>>> b: 2,
>>> c: 3,
>>> d: 4,
>>> "computed property name": "This is not part of the syntax",
>>> "new one": 5,
>>> something: Symbol(Using [[Get]])
>>> }
>>> */
>>> ```
>>>
>>> --
>>>
>>>  I would appreciate hearing your opinion on this.
>>>
>>>
>>> ___
>>> 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: try/catch/else

[Claude Pache]

> Le 9 févr. 2018 à 00:19, Peter van der Zee  a écrit :
> 
>>> On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache 
>>> wrote:
 
 What about the following pattern (labelled block + break)?
 
 ```js
 processSuggestions: {
let suggestions;
try {
  suggestions = await fetchSuggestions();
} catch (e) {
  alert('Failed to load suggestions');
  break processSuggestions;
}
showSuggestions(suggestions);
 }
 ```
> 
> I don't mean to hijack this tread. I'm mostly curious why you opt or
> even suggest for that over putting it in a function and an early
> return? Like;
> 
> ```
> function processSuggestions() {
>  let suggestions
>  try {
>suggestions = await fetchSuggestions();
>  } catch (e) {
>return alert('Failed to load suggestions');
>  }
>  showSuggestions(suggestions);
> }
> ```
> 
> This is almost identical, especially the way the example was written.
> I understand the differences, I don't think they're a problem for by
> far most cases where you'd want this.

A function is strictly more complex than a block because you have to define it 
first, then to invoke it. As a consequence, it is more code to write and read. 
Unless you have a good reason for it (which is not suggested by the original 
problem), why would you prefer the more complex way?

—Claude

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

Re: try/catch/else

[Alan Plum]

I think the best argument for having try/catch/else is that it makes it trivial 
to translate promises into async/await. Consider this:

```
let result = a()
.then(b, c)
.catch(d);
```

If we want to translate this 1:1 to try/catch/else in an async function we'll 
end up with something like this:

```
try {
  let x, y;
  try {
x = await a();
  } catch (e) {
y = await c(e);
  } else {
y = await b(x);
  }
  return y;
} catch (e) {
  return await d(e);
}
```

Doing this without `else` would require one of the workarounds suggested 
upthread.

On Thu, Feb 8, 2018, at 7:13 PM, Claude Pache wrote:
> What about the following pattern (labelled block + break)?
> 
> ```js
> processSuggestions: {
> let suggestions;
> try {
>   suggestions = await fetchSuggestions();
> } catch (e) {
>   alert('Failed to load suggestions');
>   break processSuggestions;
> }
> showSuggestions(suggestions);
> }
> ```
> 
> —Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss