Default values for nulls

[Michael Luder-Rosefield]

I know I am not the only one who has had several perfectly good use-cases
for default values disallowed, because the value coming in was `null`, not
`undefined`.

I cannot be the only one who has let bugs slip in because of failing to
consider this case.

So, if we can find a non-confusing and simple way to alter the spec to
allow for handling this, I imagine it would be considered useful and wanted.

The obvious candidate is the nullish coalescing operator, which is already
part of the spec. Unfortunately, it is currently invalid to indicate
default values with it. I can't see any reason against changing this.

```
function foo1 (x = 4) {
  console.log(x);
}

// currently causes SyntaxError
function foo2 (x ?? 4) {
  console.log(x);
}

foo1(null); // null
foo1(undefined) // 4

foo2(null); // 4
foo2(undefined) // 4

// currently causes SyntaxError
// should give x === null, y === 4
const { x = 2, y ?? 4 } = { x: null, y: null };
```
--
Dammit babies, you've got to be kind.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Private fields in sub-objects within class definition.

[Michael Theriot]

Why stop at class definitions?

e.g.
```js
let obj;
{
  let local = 0;
  obj = {
get local() {
  return local;
}
  }
}
```

becomes
```js
const obj = {
  #local: 0,
  get local() {
return this.#local;
  }
}
```

On Fri, Aug 7, 2020 at 3:33 PM #!/JoePea  wrote:

> Not sure if the following is exactly how we'd want it to be, but it
> would be useful:
>
> ```js
> class Foo {
>   // calculatedValue is intended to have read-only properties
>   calculatedValue = {
> #x: 0,
> get x() { return this.#x },
> #y: 0,
> get y() { return this.#y },
> #z: 0,
> get z() { return this.#z },
>   }
>
>   update() {
> this.calculatedValue.#x = 42 // ok
> this.calculatedValue.#y = 42 // ok
> this.calculatedValue.#z = 42 // ok
>   }
> }
> ```
>
> End user:
>
> ```js
> const foo = new Foo
> foo.calculatedValue.x // ok
> foo.calculatedValue.#x // syntax error
> ```
>
> We could currently do something like this:
>
> ```js
> class Foo {
>   #calcX = 0
>   #calcY = 0
>   #calcZ = 0
>
>   // calculatedValue is intended to have read-only properties
>   calculatedValue = (() => {
> const self = this
> return {
>   get x() { return self.#calcX },
>   get y() { return self.#calcY },
>   get z() { return self.#calcZ },
> }
>   })()
>
>   update() {
> this.#calcX = 42 // ok
> this.#calcY = 42 // ok
> this.#calcZ = 42 // ok
>   }
> }
> ```
>
> Any plans for something like this? Is there a plan for private fields
> for object literals? If so, maybe that can somehow tie into usage
> within class bodies with WeakMap-ish semantics.
>
> #!/JoePea
> ___
> 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: Why does a JavaScript class getter for a private field fail using a Proxy?

[Michael Haufe]

To quote from a short conversation I had with Allen Wirfs-Brock:

“Proxies have a similar issue WRT the "internal slots" of built-ins. The 
alternatives were the non-othogonality with Proxy or private fields whose 
privacy was insecure. TC39 choose (correctly, I think) in favor of secure field 
privacy. The lesser evil choice.”

With that being said workarounds have already been presented:

https://github.com/tc39/proposal-class-fields/issues/106#issuecomment-397484713
https://javascript.info/proxy#private-fields



From: es-discuss  On Behalf Of Michael Theriot
Sent: Sunday, July 12, 2020 5:10 PM
To: kai zhu 
Cc: es-discuss@mozilla.org
Subject: Re: Why does a JavaScript class getter for a private field fail using 
a Proxy?

I assume OP wants to use proxies and private members together. They are not 
designed to be compatible.

Proxies and private members are a UX goal primarily for developers. Proxies 
easily allow observation of another object or creation of exotic objects (e.g. 
Array), and private members (safely) allow classes with internal slots. Since 
they cannot be used together the issue exists, and the hack circumvents this by 
reimplementing private in a way that does not require private fields.

On Sun, Jul 12, 2020 at 4:45 PM kai zhu 
mailto:kaizhu...@gmail.com>> wrote:
as product-developer, can i ask what ux-objective you ultimately want achieved?

```js
const sub = new Sub()

// i'm a noob on proxies. what is this thing (with proxied-private-fields) 
ultimately used for?
const proxy = new Proxy(sub, ...)
```

On Sun, Jul 12, 2020 at 4:34 PM Michael Theriot 
mailto:michael.lee.ther...@gmail.com>> wrote:
This does require you to have both the key and the weakmap though, so it 
actually does succeed in hiding the data so long as the weakmap is out of 
scope. I guess the issue I can foresee is that the key could be modified after 
the object is created.

e.g.
```js
var a = new A();
var key = Object.getOwnPropertySymbols(a)[0];
delete a[key];
a.hidden; // throws
```

That itself can be guarded by just making the key undeletable. So, I guess this 
solution could work depending what your goals are?

On Sun, Jul 12, 2020 at 4:21 PM Michael Theriot 
mailto:michael.lee.ther...@gmail.com>> wrote:
It nearly works, but the issue is that the key will be leaked by 
`Object.getOwnPropertySymbols(new A())`, so it's not truly private.

There have been ideas proposing "private symbols" but I am not familiar with 
their issues, and I would guess with Class Fields they are unlikely to 
materialize anyway.

On Sun, Jul 12, 2020 at 2:19 PM François REMY 
mailto:francois.remy@outlook.com>> wrote:
At the risk of pointing out the obvious:

```js
const privkey = Symbol();
const stores = new WeakMap();

class A {
  [privkey] = {};
  constructor() {
const priv = {};
priv.hidden = Math.random();
stores.set(this[privkey], priv);
  }

  get hidden() {
const priv = stores.get(this[privkey]);
return priv.hidden;
  }
}

var as = [
new A(),
new Proxy(new A(),{}),
new Proxy(new A(),{}),
];
console.log(as.map(a=>a.hidden));
```



From: Michael Theriot<mailto:michael.lee.ther...@gmail.com>
Sent: Sunday, July 12, 2020 20:59
To: Michael Haufe<mailto:t...@thenewobjective.com>
Cc: es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
Subject: Re: Why does a JavaScript class getter for a private field fail using 
a Proxy?

I experienced this issue prior to this proposal, using weakmaps for private 
access.

e.g.
```js
const stores = new WeakMap();

class A {
  constructor() {
const priv = {};
priv.hidden = 0;
stores.set(this, priv);
  }

  get hidden() {
const priv = stores.get(this);
return priv.hidden;
  }
}

const a = new A();
console.log(a.hidden); // 0

const p = new Proxy(a, {});
console.log(p.hidden); // throws!
```

I found a workaround:

```js
const stores = new WeakMap();

class A {
  constructor() {
const priv = {};
priv.hidden = 0;
stores.set(this, priv);

const p = new Proxy(this, {});
stores.set(p, priv); // set proxy to map to the same private store

return p;
  }

  get hidden() {
const priv = stores.get(this); // the original instance and proxy both map 
to the same private store now
return priv.hidden;
  }
}

const a = new A();

console.log(a.hidden);
```

Not ideal, and only works if you provide the proxy in the first place (e.g. 
making exotic JS objects). But, not necessarily a new issue with proxies, 
either.

On Fri, Jun 5, 2020 at 12:29 AM Michael Haufe 
mailto:t...@thenewobjective.com>> wrote:
This is a known issue and very painful for me as well. You can see a long ugly 
discussion here:

<https://github.com/tc39/proposal-class-fields/issues/106>

I suggest the following guide to assist you:

<https://javascript.info/proxy#proxy-limitations>

Another possible approach is to have your classes extend a pr

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

[Michael Theriot]

I assume OP wants to use proxies and private members together. They are not
designed to be compatible.

Proxies and private members are a UX goal primarily for developers. Proxies
easily allow observation of another object or creation of exotic objects
(e.g. Array), and private members (safely) allow classes with internal
slots. Since they cannot be used together the issue exists, and the hack
circumvents this by reimplementing private in a way that does not require
private fields.

On Sun, Jul 12, 2020 at 4:45 PM kai zhu  wrote:

> as product-developer, can i ask what ux-objective you ultimately want
> achieved?
>
> ```js
> const sub = new Sub()
>
> // i'm a noob on proxies. what is this thing (with proxied-private-fields)
> ultimately used for?
> const proxy = new Proxy(sub, ...)
> ```
>
> On Sun, Jul 12, 2020 at 4:34 PM Michael Theriot <
> michael.lee.ther...@gmail.com> wrote:
>
>> This does require you to have both the key and the weakmap though, so it
>> actually does succeed in hiding the data so long as the weakmap is out of
>> scope. I guess the issue I can foresee is that the key could be modified
>> after the object is created.
>>
>> e.g.
>> ```js
>> var a = new A();
>> var key = Object.getOwnPropertySymbols(a)[0];
>> delete a[key];
>> a.hidden; // throws
>> ```
>>
>> That itself can be guarded by just making the key undeletable. So, I
>> guess this solution could work depending what your goals are?
>>
>> On Sun, Jul 12, 2020 at 4:21 PM Michael Theriot <
>> michael.lee.ther...@gmail.com> wrote:
>>
>>> It nearly works, but the issue is that the key will be leaked by
>>> `Object.getOwnPropertySymbols(new A())`, so it's not truly private.
>>>
>>> There have been ideas proposing "private symbols" but I am not familiar
>>> with their issues, and I would guess with Class Fields they are unlikely to
>>> materialize anyway.
>>>
>>> On Sun, Jul 12, 2020 at 2:19 PM François REMY <
>>> francois.remy@outlook.com> wrote:
>>>
>>>> At the risk of pointing out the obvious:
>>>>
>>>>
>>>>
>>>> ```js
>>>>
>>>> const privkey = Symbol();
>>>>
>>>> const stores = new WeakMap();
>>>>
>>>>
>>>>
>>>> class A {
>>>>
>>>>   [privkey] = {};
>>>>
>>>>   constructor() {
>>>>
>>>> const priv = {};
>>>>
>>>>     priv.hidden = Math.random();
>>>>
>>>> stores.set(this[privkey], priv);
>>>>
>>>>   }
>>>>
>>>>
>>>>
>>>>   get hidden() {
>>>>
>>>> const priv = stores.get(this[privkey]);
>>>>
>>>> return priv.hidden;
>>>>
>>>>   }
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> var as = [
>>>>
>>>> new A(),
>>>>
>>>> new Proxy(new A(),{}),
>>>>
>>>> new Proxy(new A(),{}),
>>>>
>>>> ];
>>>>
>>>> console.log(as.map(a=>a.hidden));
>>>>
>>>> ```
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: *Michael Theriot 
>>>> *Sent: *Sunday, July 12, 2020 20:59
>>>> *To: *Michael Haufe 
>>>> *Cc: *es-discuss@mozilla.org
>>>> *Subject: *Re: Why does a JavaScript class getter for a private field
>>>> fail using a Proxy?
>>>>
>>>>
>>>>
>>>> I experienced this issue prior to this proposal, using weakmaps for
>>>> private access.
>>>>
>>>>
>>>>
>>>> e.g.
>>>>
>>>> ```js
>>>>
>>>> const stores = new WeakMap();
>>>>
>>>> class A {
>>>>   constructor() {
>>>> const priv = {};
>>>> priv.hidden = 0;
>>>> stores.set(this, priv);
>>>>   }
>>>>
>>>>   get hidden() {
>>>> const priv = stores.get(this);
>>>> return priv.hidden;
>>>>   }
>>>> }
>>>>
>>>> const a = new A();
>>>> console.log(a.hidden); // 0
>>>>
>>>> const p = new Proxy(a, {});
>>>> console.log(p.hi

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

[Michael Theriot]

This does require you to have both the key and the weakmap though, so it
actually does succeed in hiding the data so long as the weakmap is out of
scope. I guess the issue I can foresee is that the key could be modified
after the object is created.

e.g.
```js
var a = new A();
var key = Object.getOwnPropertySymbols(a)[0];
delete a[key];
a.hidden; // throws
```

That itself can be guarded by just making the key undeletable. So, I guess
this solution could work depending what your goals are?

On Sun, Jul 12, 2020 at 4:21 PM Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> It nearly works, but the issue is that the key will be leaked by
> `Object.getOwnPropertySymbols(new A())`, so it's not truly private.
>
> There have been ideas proposing "private symbols" but I am not familiar
> with their issues, and I would guess with Class Fields they are unlikely to
> materialize anyway.
>
> On Sun, Jul 12, 2020 at 2:19 PM François REMY <
> francois.remy@outlook.com> wrote:
>
>> At the risk of pointing out the obvious:
>>
>>
>>
>> ```js
>>
>> const privkey = Symbol();
>>
>> const stores = new WeakMap();
>>
>>
>>
>> class A {
>>
>>   [privkey] = {};
>>
>>   constructor() {
>>
>> const priv = {};
>>
>> priv.hidden = Math.random();
>>
>> stores.set(this[privkey], priv);
>>
>>   }
>>
>>
>>
>>   get hidden() {
>>
>> const priv = stores.get(this[privkey]);
>>
>> return priv.hidden;
>>
>>   }
>>
>> }
>>
>>
>>
>> var as = [
>>
>> new A(),
>>
>> new Proxy(new A(),{}),
>>
>> new Proxy(new A(),{}),
>>
>> ];
>>
>> console.log(as.map(a=>a.hidden));
>>
>> ```
>>
>>
>>
>>
>>
>>
>>
>> *From: *Michael Theriot 
>> *Sent: *Sunday, July 12, 2020 20:59
>> *To: *Michael Haufe 
>> *Cc: *es-discuss@mozilla.org
>> *Subject: *Re: Why does a JavaScript class getter for a private field
>> fail using a Proxy?
>>
>>
>>
>> I experienced this issue prior to this proposal, using weakmaps for
>> private access.
>>
>>
>>
>> e.g.
>>
>> ```js
>>
>> const stores = new WeakMap();
>>
>> class A {
>>   constructor() {
>> const priv = {};
>> priv.hidden = 0;
>> stores.set(this, priv);
>>   }
>>
>>   get hidden() {
>> const priv = stores.get(this);
>> return priv.hidden;
>>   }
>> }
>>
>> const a = new A();
>> console.log(a.hidden); // 0
>>
>> const p = new Proxy(a, {});
>> console.log(p.hidden); // throws!
>>
>> ```
>>
>>
>>
>> I found a workaround:
>>
>>
>>
>> ```js
>> const stores = new WeakMap();
>>
>> class A {
>>   constructor() {
>> const priv = {};
>> priv.hidden = 0;
>> stores.set(this, priv);
>>
>> const p = new Proxy(this, {});
>> stores.set(p, priv); // set proxy to map to the same private store
>>
>> return p;
>>   }
>>
>>   get hidden() {
>> const priv = stores.get(this); // the original instance and proxy
>> both map to the same private store now
>> return priv.hidden;
>>   }
>> }
>>
>> const a = new A();
>>
>> console.log(a.hidden);
>> ```
>>
>>
>>
>> Not ideal, and only works if you provide the proxy in the first place
>> (e.g. making exotic JS objects). But, not necessarily a new issue with
>> proxies, either.
>>
>>
>>
>> On Fri, Jun 5, 2020 at 12:29 AM Michael Haufe 
>> wrote:
>>
>> This is a known issue and very painful for me as well. You can see a long
>> ugly discussion here:
>>
>>
>>
>> <https://github.com/tc39/proposal-class-fields/issues/106>
>>
>>
>>
>> I suggest the following guide to assist you:
>>
>>
>>
>> <https://javascript.info/proxy#proxy-limitations>
>>
>>
>>
>> Another possible approach is to have your classes extend a proxy:
>>
>>
>>
>> <
>> https://github.com/tc39/proposal-class-fields/issues/106#issuecomment-397484713
>> >
>>
>>
>>
>>
>>
>> *From:* es-discuss  *On Behalf Of *Laurie
>> Harper
>> *Sent:* Friday, June 5, 2020 12:21 AM
>> *To:* es-discuss@mozilla.org
>>

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

[Michael Theriot]

It nearly works, but the issue is that the key will be leaked by
`Object.getOwnPropertySymbols(new A())`, so it's not truly private.

There have been ideas proposing "private symbols" but I am not familiar
with their issues, and I would guess with Class Fields they are unlikely to
materialize anyway.

On Sun, Jul 12, 2020 at 2:19 PM François REMY 
wrote:

> At the risk of pointing out the obvious:
>
>
>
> ```js
>
> const privkey = Symbol();
>
> const stores = new WeakMap();
>
>
>
> class A {
>
>   [privkey] = {};
>
>   constructor() {
>
> const priv = {};
>
> priv.hidden = Math.random();
>
> stores.set(this[privkey], priv);
>
>   }
>
>
>
>   get hidden() {
>
> const priv = stores.get(this[privkey]);
>
> return priv.hidden;
>
>   }
>
> }
>
>
>
> var as = [
>
> new A(),
>
>     new Proxy(new A(),{}),
>
> new Proxy(new A(),{}),
>
> ];
>
> console.log(as.map(a=>a.hidden));
>
> ```
>
>
>
>
>
>
>
> *From: *Michael Theriot 
> *Sent: *Sunday, July 12, 2020 20:59
> *To: *Michael Haufe 
> *Cc: *es-discuss@mozilla.org
> *Subject: *Re: Why does a JavaScript class getter for a private field
> fail using a Proxy?
>
>
>
> I experienced this issue prior to this proposal, using weakmaps for
> private access.
>
>
>
> e.g.
>
> ```js
>
> const stores = new WeakMap();
>
> class A {
>   constructor() {
> const priv = {};
> priv.hidden = 0;
> stores.set(this, priv);
>   }
>
>   get hidden() {
> const priv = stores.get(this);
> return priv.hidden;
>   }
> }
>
> const a = new A();
> console.log(a.hidden); // 0
>
> const p = new Proxy(a, {});
> console.log(p.hidden); // throws!
>
> ```
>
>
>
> I found a workaround:
>
>
>
> ```js
> const stores = new WeakMap();
>
> class A {
>   constructor() {
> const priv = {};
> priv.hidden = 0;
> stores.set(this, priv);
>
> const p = new Proxy(this, {});
> stores.set(p, priv); // set proxy to map to the same private store
>
> return p;
>   }
>
>   get hidden() {
> const priv = stores.get(this); // the original instance and proxy both
> map to the same private store now
> return priv.hidden;
>   }
> }
>
> const a = new A();
>
> console.log(a.hidden);
> ```
>
>
>
> Not ideal, and only works if you provide the proxy in the first place
> (e.g. making exotic JS objects). But, not necessarily a new issue with
> proxies, either.
>
>
>
> On Fri, Jun 5, 2020 at 12:29 AM Michael Haufe 
> wrote:
>
> This is a known issue and very painful for me as well. You can see a long
> ugly discussion here:
>
>
>
> <https://github.com/tc39/proposal-class-fields/issues/106>
>
>
>
> I suggest the following guide to assist you:
>
>
>
> <https://javascript.info/proxy#proxy-limitations>
>
>
>
> Another possible approach is to have your classes extend a proxy:
>
>
>
> <
> https://github.com/tc39/proposal-class-fields/issues/106#issuecomment-397484713
> >
>
>
>
>
>
> *From:* es-discuss  *On Behalf Of *Laurie
> Harper
> *Sent:* Friday, June 5, 2020 12:21 AM
> *To:* es-discuss@mozilla.org
> *Subject:* Why does a JavaScript class getter for a private field fail
> using a Proxy?
>
>
>
> I can expose private class fields in JavaScript using getters, and those
> getters work correctly when invoked on instances of a subclass. However, if
> I then wrap the instance with a proxy the getter will throw a type error,
> even if the proxy `get` hook uses `Reflect.get()`:
>
> ```
> class Base {
> _attrA
> #_attrB
>
> constructor() {
> this._attrA = 100
> this.#_attrB = 200
> }
>
> get A() { return this._attrA }
>
> get B() { return this.#_attrB }
>
> incrA() { this._attrA++ }
>
> incrB() { this.#_attrB++ }
> }
>
> class Sub extends Base {}
>
> const sub = new Sub()
>
> const proxy = new Proxy(sub, {
> get(target, prop, receiver) {
> const value = Reflect.get(target, prop, receiver)
> return typeof value === 'function' ? value.bind(target) : value //
> (1)
> }
> })
>
> console.log('sub.A', sub.A) // OK: -> 100
> console.log('sub.B', sub.B) // OK: -> 200
> sub.incrA() // OK
> sub.incrB() // OK
> console.log('sub.A', sub.A) // OK: -> 101
> console.log('sub.B', sub.B) // OK: -> 201
>
> console.log('proxy.A', proxy.A) // OK: -> 100
> conso

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

[Michael Theriot]

I experienced this issue prior to this proposal, using weakmaps for private
access.

e.g.
```js
const stores = new WeakMap();

class A {
  constructor() {
const priv = {};
priv.hidden = 0;
stores.set(this, priv);
  }

  get hidden() {
const priv = stores.get(this);
return priv.hidden;
  }
}

const a = new A();
console.log(a.hidden); // 0

const p = new Proxy(a, {});
console.log(p.hidden); // throws!
```

I found a workaround:

```js
const stores = new WeakMap();

class A {
  constructor() {
const priv = {};
priv.hidden = 0;
stores.set(this, priv);

const p = new Proxy(this, {});
stores.set(p, priv); // set proxy to map to the same private store

return p;
  }

  get hidden() {
const priv = stores.get(this); // the original instance and proxy both
map to the same private store now
return priv.hidden;
  }
}

const a = new A();

console.log(a.hidden);
```

Not ideal, and only works if you provide the proxy in the first place (e.g.
making exotic JS objects). But, not necessarily a new issue with proxies,
either.

On Fri, Jun 5, 2020 at 12:29 AM Michael Haufe 
wrote:

> This is a known issue and very painful for me as well. You can see a long
> ugly discussion here:
>
>
>
> <https://github.com/tc39/proposal-class-fields/issues/106>
>
>
>
> I suggest the following guide to assist you:
>
>
>
> <https://javascript.info/proxy#proxy-limitations>
>
>
>
> Another possible approach is to have your classes extend a proxy:
>
>
>
> <
> https://github.com/tc39/proposal-class-fields/issues/106#issuecomment-397484713
> >
>
>
>
>
>
> *From:* es-discuss  * On Behalf Of *Laurie
> Harper
> *Sent:* Friday, June 5, 2020 12:21 AM
> *To:* es-discuss@mozilla.org
> *Subject:* Why does a JavaScript class getter for a private field fail
> using a Proxy?
>
>
>
> I can expose private class fields in JavaScript using getters, and those
> getters work correctly when invoked on instances of a subclass. However, if
> I then wrap the instance with a proxy the getter will throw a type error,
> even if the proxy `get` hook uses `Reflect.get()`:
>
> ```
> class Base {
> _attrA
> #_attrB
>
> constructor() {
> this._attrA = 100
> this.#_attrB = 200
> }
>
> get A() { return this._attrA }
>
> get B() { return this.#_attrB }
>
> incrA() { this._attrA++ }
>
> incrB() { this.#_attrB++ }
> }
>
> class Sub extends Base {}
>
> const sub = new Sub()
>
> const proxy = new Proxy(sub, {
> get(target, prop, receiver) {
> const value = Reflect.get(target, prop, receiver)
> return typeof value === 'function' ? value.bind(target) : value //
> (1)
> }
> })
>
> console.log('sub.A', sub.A) // OK: -> 100
> console.log('sub.B', sub.B) // OK: -> 200
> sub.incrA() // OK
> sub.incrB() // OK
> console.log('sub.A', sub.A) // OK: -> 101
> console.log('sub.B', sub.B) // OK: -> 201
>
> console.log('proxy.A', proxy.A) // OK: -> 100
> console.log('proxy.B', proxy.B) // TypeError: Cannot read private member
> #_attrB from an object whose class did not declare it
> proxy.incrA() // OK
> proxy.incrB() // OK due to (1)
> console.log('proxy.A', proxy.A) // OK: -> 100
> console.log('proxy.B', proxy.B) // TypeError: Cannot read private member
> #_attrB from an object whose class did not declare it
> ```
>
> The call to `proxy.incrB()` works, because the proxy handler explicitly
> binds function values to `target` on line (1). Without the `bind()` call,
> the `proxy.incrB()` invocation would throw a `TypeError` like the getter
> invocation does. That makes some sense: the result of the call to
> `Reflect.get()` is the 'unbound' function value of the property being
> retrieved, which must then be bound to `target`; it would make more sense,
> though, if `this` binding was applied by the [[Call]] operation on the
> result of the [[Get]] operation...
>
> But there is no opportunity to 'bind' a getter before invoking it; as a
> result, a proxied getter ends up receiving the wrong `this` binding,
> leading to the inconsistency.
>
> Is there any way to make this work correctly? The only approach I can
> think of (which I haven't tried) would be to have the `get` hook walk up
> the prototype chain, starting from `target`, calling
> `getOwnPropertyDescriptor()` and checking for a getter method, and
> explicitly applying the getter with an adjusted `this` binding. That sounds
> ludicrously cumbersome and brittle...
>
> Is there a better way to get this working correctly?
>
>
>
> --
>
> Laurie
> ___
> 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: Why does a JavaScript class getter for a private field fail using a Proxy?

[Michael Haufe]

This is a known issue and very painful for me as well. You can see a long ugly 
discussion here:



I suggest the following guide to assist you:



Another possible approach is to have your classes extend a proxy:




From: es-discuss  On Behalf Of Laurie Harper
Sent: Friday, June 5, 2020 12:21 AM
To: es-discuss@mozilla.org
Subject: Why does a JavaScript class getter for a private field fail using a 
Proxy?

I can expose private class fields in JavaScript using getters, and those 
getters work correctly when invoked on instances of a subclass. However, if I 
then wrap the instance with a proxy the getter will throw a type error, even if 
the proxy `get` hook uses `Reflect.get()`:

```
class Base {
_attrA
#_attrB

constructor() {
this._attrA = 100
this.#_attrB = 200
}

get A() { return this._attrA }

get B() { return this.#_attrB }

incrA() { this._attrA++ }

incrB() { this.#_attrB++ }
}

class Sub extends Base {}

const sub = new Sub()

const proxy = new Proxy(sub, {
get(target, prop, receiver) {
const value = Reflect.get(target, prop, receiver)
return typeof value === 'function' ? value.bind(target) : value // (1)
}
})

console.log('sub.A', sub.A) // OK: -> 100
console.log('sub.B', sub.B) // OK: -> 200
sub.incrA() // OK
sub.incrB() // OK
console.log('sub.A', sub.A) // OK: -> 101
console.log('sub.B', sub.B) // OK: -> 201

console.log('proxy.A', proxy.A) // OK: -> 100
console.log('proxy.B', proxy.B) // TypeError: Cannot read private member 
#_attrB from an object whose class did not declare it
proxy.incrA() // OK
proxy.incrB() // OK due to (1)
console.log('proxy.A', proxy.A) // OK: -> 100
console.log('proxy.B', proxy.B) // TypeError: Cannot read private member 
#_attrB from an object whose class did not declare it
```

The call to `proxy.incrB()` works, because the proxy handler explicitly binds 
function values to `target` on line (1). Without the `bind()` call, the 
`proxy.incrB()` invocation would throw a `TypeError` like the getter invocation 
does. That makes some sense: the result of the call to `Reflect.get()` is the 
'unbound' function value of the property being retrieved, which must then be 
bound to `target`; it would make more sense, though, if `this` binding was 
applied by the [[Call]] operation on the result of the [[Get]] operation...

But there is no opportunity to 'bind' a getter before invoking it; as a result, 
a proxied getter ends up receiving the wrong `this` binding, leading to the 
inconsistency.

Is there any way to make this work correctly? The only approach I can think of 
(which I haven't tried) would be to have the `get` hook walk up the prototype 
chain, starting from `target`, calling `getOwnPropertyDescriptor()` and 
checking for a getter method, and explicitly applying the getter with an 
adjusted `this` binding. That sounds ludicrously cumbersome and brittle...

Is there a better way to get this working correctly?

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

RE: Yet another attempt at typed JS data

[Michael Haufe]

Given your history I know better than to assume what you know…

The definition of sparse in the spec (while not explicitly in its own section) 
is straightforward.

V8’s inability or unwillingness to perform a safe “upcast” internally to an 
appropriate tag doesn’t seem to provide enough weight to introduce a new 
construct.


From: Andrea Giammarchi 
Sent: Monday, February 10, 2020 2:26 PM
To: Michael Haufe 
Cc: Bergi ; es-discuss@mozilla.org
Subject: Re: Yet another attempt at typed JS data

Great, now maybe you also read how it works behind the scene, and debug 
properly to understand that every array is holey, including the latter one, to 
date.

https://v8.dev/blog/elements-kinds

Please, let's assume for a second I knew what I was talking about, when I've 
said it's a mess to not have holey arrays, thanks.

On Mon, Feb 10, 2020 at 9:21 PM Michael Haufe 
mailto:t...@thenewobjective.com>> wrote:
Array(3)
//  [empty × 3]

Array(3).fill()
// [undefined, undefined, undefined]

Array(3).fill('whatever')
// ["whatever", "whatever", "whatever"]


-Original Message-
From: es-discuss 
mailto:es-discuss-boun...@mozilla.org>> On 
Behalf Of Bergi
Sent: Monday, February 10, 2020 1:27 PM
To: es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
Subject: Re: Yet another attempt at typed JS data

Hello!

> Unfortunately, `Array.from({ length: 4 }, () => whatever)` produces a
> holey array

Does it? But really, if the performance difference betweeen HOLEY and PACKED 
arrays were large enough to be relevant[1], the engine programmers would 
certainly already have optimised all those trivial cases where an array is 
filled gradually to produce the more efficient representation.

kind regards,
 Bergi

[1]: it probably isn't:
https://stackoverflow.com/questions/54481918/#comment95848513_54485509
___
es-discuss mailing list
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org<mailto: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: Yet another attempt at typed JS data

[Michael Haufe]

Array(3)
//  [empty × 3]

Array(3).fill()
// [undefined, undefined, undefined]

Array(3).fill('whatever')
// ["whatever", "whatever", "whatever"]


-Original Message-
From: es-discuss  On Behalf Of Bergi
Sent: Monday, February 10, 2020 1:27 PM
To: es-discuss@mozilla.org
Subject: Re: Yet another attempt at typed JS data

Hello!

> Unfortunately, `Array.from({ length: 4 }, () => whatever)` produces a 
> holey array

Does it? But really, if the performance difference betweeen HOLEY and PACKED 
arrays were large enough to be relevant[1], the engine programmers would 
certainly already have optimised all those trivial cases where an array is 
filled gradually to produce the more efficient representation.

kind regards,
 Bergi

[1]: it probably isn't:
https://stackoverflow.com/questions/54481918/#comment95848513_54485509
___
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: Property Accessor Function Shorthand

[Michael Luder-Rosefield]

At the cost of adding more code, but giving more power, perhaps what we
want is something akin to Kotlin's `it` keyword:
https://kotlinlang.org/docs/reference/lambdas.html?_ga=2.238822404.500195435.1575368476-1345353619.1575368476#it-implicit-name-of-a-single-parameter

*it: implicit name of a single parameter*
*It's very common that a lambda expression has only one parameter.*
*If the compiler can figure the signature out itself, it is allowed not to
declare the only parameter and omit ->. The parameter will be implicitly
declared under the name it:*
ints.filter { it > 0 } // this literal is of type '(it: Int) -> Boolean'


What we'd want is something concise and non-ambiguous to fulfill the same
role; something that cannot currently be a valid identifier, maybe. This is
the point where I start scanning the keyboard for underutilised symbols...
I'm thinking the hash symbol would work. To re-use the original example:

```js
const activeProducts = products.filter(#.active);
const productNames = products.map(#.name);
const sortedProducts = _.sortBy(products, #.name);
const { true: activeProducts, false: inactiveProducts } =
_.groupBy(products, #.active);
```

It makes intuitive sense in 2 ways, I think; # makes you think of the
object hash you're extracting a property from, and also is familiar as
something's id from CSS selectors.

We could also extend it to represent multiple parameters: # is also aliased
as #0, the 2nd parameter is #1, etc.

Further, dynamic properties would work too: `const fooProducts =
products.filter(#[foo]);
*-*-
Dammit babies, you've got to be kind.


On Mon, 2 Dec 2019 at 22:32, Waldemar Horwat  wrote:

> On 11/24/19 9:17 PM, Bob Myers wrote:
> > FWIW, the syntax `.propName` does appear to be syntactically unambiguous.
>
> It conflicts with contextual keywords such as `new . target`.
>
>  Waldemar
> ___
> 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: Ternary operator enhancement proposal

[Michael Luder-Rosefield]

I put forward a similar proposal a while back:
https://esdiscuss.org/topic/proposal-result-forwarding-ternary-operator
--
Dammit babies, you've got to be kind.


On Wed, 13 Nov 2019 at 02:46, Jacob Pratt  wrote:

> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modify Promise.all() to accept an Object as a parameter

[Michael Luder-Rosefield]

The RSVP library uses Promise.hash, which seems sensible enough that I'm
surprised no-one has mentioned or suggested it here.
--
Dammit babies, you've got to be kind.


On Mon, 14 Oct 2019 at 09:17, Michał Wadas  wrote:

> Established name is Promise.properties
>
> On Mon, 14 Oct 2019, 09:29 Cyril Auburtin, 
> wrote:
>
>> maybe a naming like: `Promise.allObject`
>>
>> ```js
>> Promise.allObject = obj => {
>>   if (obj && !obj[Symbol.iterator]) {
>> return Promise.all(
>>   Object.entries(obj).map(async ([k, v]) => [k, await v])
>> )
>>   .then(Object.fromEntries);
>>   }
>>   return Promise.all(obj);
>> }
>>
>> var delay = t => new Promise(r => setTimeout(r, t));
>> console.time(1); console.log(await Promise.allObject({foo:
>> delay(110).then(()=>1), bar: delay(120).then(()=>2)})); console.timeEnd(1)
>> ```
>>
>> On Sun, Oct 13, 2019 at 8:55 PM Isiah Meadows 
>> wrote:
>>
>>> Maybe Promise.join(object)? Also, if a map is passed (or any iterable),
>>> it should be joined into a map.
>>>
>>> At the most basic level:
>>>
>>> ```js
>>> Promise.join = (o) => {
>>> let isMap = o[Symbol.iterator] != null
>>> let ps = (
>>> isMap ? Array.from : Object.entries
>>> )(o)
>>> let ks = ps.map(p => p[0])
>>> return Promise.all(ps.map(p => p[1]))
>>> .then(vs => {
>>> let ps = vs.map((v, i) => [ks[i], v])
>>> return isMap
>>> ? new Map(ps)
>>> : Object.fromEntries(ps)
>>> })
>>> }
>>> ```
>>>
>>> On Sun, Oct 13, 2019 at 13:40 Cyril Auburtin 
>>> wrote:
>>>
 OP probably means he would like Promise.all to return an object as
 well, if an object if given

 It's possible to hack an object to be iterable, but Promise.all
 already return an array unfortunately

 On Sun, Oct 13, 2019 at 7:16 PM Boris Zbarsky  wrote:

> On 10/12/19 12:52 AM, Jacob Bloom wrote:
> > const responses = await Promise.all(requests);
>
> As opposed to:
>
>const responses = await Primise.all(requests.values());
>
> which works right now?
>
> -Boris
> ___
> 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

>>> --
>>> -
>>>
>>> Isiah Meadows
>>> cont...@isiahmeadows.com
>>> www.isiahmeadows.com
>>>
>> ___
>> 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: Use hashes as keys instead of toString() for values like object, function to index objects

[Michael Luder-Rosefield]

Why not both?

My point is that Map/WeakMap do a lot of what people historically use
Object for, but in a better way; certainly, they solve Tadas's issue here.

The trouble is that Objects have a lot of convenient sugar around them that
make them easier, and more pleasant, to use. We really shouldn't be in a
position where people choose the worse option simply out of sugar.

--
Dammit babies, you've got to be kind.


On Mon, 9 Sep 2019 at 02:26, J Decker  wrote:

>
>
> On Sun, Sep 8, 2019 at 1:24 PM Michael Luder-Rosefield <
> rosyatran...@gmail.com> wrote:
>
>> I'd suggest that the best way of doing this, without breaking existing
>> code, is to put some sugar around Maps so that they can be used in a more
>> Object-y way. For starters, Map literal declarations and assignment could
>> benefit from this.
>>
>> or Just use a WeakMap
>
>
>> Suggestions for syntax welcome!
>>
>> On Sun, 8 Sep 2019, 12:36 Tadas Lapė,  wrote:
>>
>>> The problem
>>>
>>> Javascript allows to index objects not only with strings, numbers, but
>>> also with objects. It uses toString() object method to calculate the object
>>> index. If method is not overwritten, the generated index is "[object
>>> Object]". Many users do not know this or forget this and cause different
>>> objects going into same index when using more of them.
>>>
>>> The solution
>>>
>>> Instead of using the default value "[object Object]" for objects, use
>>> their hash codes. You can also prepend them with "function:" or "object:"
>>> to let the user know index origin when iterating over object keys. And if
>>> person has overwritten the behavior of toString() object method, use it's
>>> returned value as index (to consider). This should be less error-prone.
>>> ___
>>> 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: Use hashes as keys instead of toString() for values like object, function to index objects

[Michael Luder-Rosefield]

I'd suggest that the best way of doing this, without breaking existing
code, is to put some sugar around Maps so that they can be used in a more
Object-y way. For starters, Map literal declarations and assignment could
benefit from this.

Suggestions for syntax welcome!

On Sun, 8 Sep 2019, 12:36 Tadas Lapė,  wrote:

> The problem
>
> Javascript allows to index objects not only with strings, numbers, but
> also with objects. It uses toString() object method to calculate the object
> index. If method is not overwritten, the generated index is "[object
> Object]". Many users do not know this or forget this and cause different
> objects going into same index when using more of them.
>
> The solution
>
> Instead of using the default value "[object Object]" for objects, use
> their hash codes. You can also prepend them with "function:" or "object:"
> to let the user know index origin when iterating over object keys. And if
> person has overwritten the behavior of toString() object method, use it's
> returned value as index (to consider). This should be less error-prone.
> ___
> 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 chaining syntax but with the "mice" operator ?

[Michael Luder-Rosefield]

This is getting very reminiscent of my 'forwarding ternary' operator (or
whatever I called it) I suggested a couple of years ago. I believe you were
involved in the discussion, Andrea...!

```
const val = foo() ?!
  (x) => x.bar.baz :
  someFallbackValue;
```

On Sat, 7 Sep 2019, 10:17 Andrea Giammarchi, 
wrote:

> To better answer, let's start dropping any direct access and put a payload
> in the mix.
>
> As example, in the `foo()?.bar.baz` case, you might end up having `null`
> or `undefined`, as result, because `foo().bar` existed, but `bar.baz`
> didn't.
>
> In the `foo()?.bar?.baz` case, you might end up having `foo().bar`,
> because `bar.baz` didn't exist.
>
> But what if you are not interested in the whole chain, but only in a main
> specific point in such chain? In that case you would have `foo()?.bar.baz
> ?? foo()`, but you wouldn't know how to obtain that via `foo()?.bar?.baz ??
> foo()`, because the latest one might result into `foo().bar`.
>
> Moreover, in both cases you'll end up multiplying the payload at least *
> 2, while the mouse trap will work like this:
>
> ```js
> foo() ```
>
> if either `foo().bar` or `bar.baz` don't exist, the returned result is
> `foo()`, and it's computed once. You don't care about `foo().bar` if
> `bar.baz` is not there, 'cause you want to retrieve `foo()` whenever you
> have a failure down the chain.
>
> Specially with DB operations, this is a very common case (abstraction
> layers all have somehow different nested objects with various info) and the
> specific info you want to know is usually attached at the top level bject,
> while crawling its sub properties either leads to the expected result or
> you're left clueless about the result, 'cause all info got lost in the
> chain.
>
> The `foo() `foo().bar` existed, there's no way to expect `foo()` as result, and if
> it's `bar` that you're after you can write instead `foo()?.bar that if `baz` is not there, `bar` it is.
>
> This short-circuit the need for `??` in most cases, 'cause you already
> point at the desired result in the chain in case the result would be `null`
> or `undefined`.
>
> However, `??` itself doesn't provide any ability to reach any point in the
> previous chain that failed, so that once again, you find yourself crawling
> such chain as fallback, resulting potentially in multiple chains and
> repeated payloads.
>
> ```js
> // nested chains
> foo()?.bar.baz?.biz ?? foo()?.bar.baz ?? foo()?.bar;
>
> // mouse trap
> foo()?.bar ```
>
> Above example would prefer `foo().bar` if it exists, and if either
> `bar.baz` or `bar.baz.biz` returned `null` or `undefined`.
>
> I hope this clarifies further the intent, or the simplification, that such
> operator offers: it's a complementary hint for any optional chain, it
> doesn't have to be used, but when it does, it's visually semantic in its
> intent (at least to my eyes).
>
> Regards
>
>
>
>
> On Fri, Sep 6, 2019 at 11:20 PM Tab Atkins Jr. 
> wrote:
>
>> On Fri, Sep 6, 2019 at 8:04 AM Andrea Giammarchi
>>  wrote:
>> > Indeed I'm not super convinced myself about the "branching issue"
>> 'cause `const result = this?.is?.branching?.already` and all I am proposing
>> is to hint the syntax where to stop in case something else fails down the
>> line, as in `const result = this.?.is> other part is not reached, there is a certain point to keep going (which
>> is, example, checking that `result !== this`)
>>
>> Important distinction there is that ?. only "branches" between the
>> intended type and undefined, not between two arbitrary types. The
>> cognitive load between those two is significantly different.
>>
>> In particular, you can't *do* anything with undefined, so
>> `foo?.bar.baz` has pretty unambiguous semantics - you don't think you
>> might be accessing the .baz property of undefined, because that
>> clearly doesn't exist.
>>
>> That's not the case with mouse, where it's not clear, at least to me,
>> whether `foo> `foo.bar.baz ? foo.bar.baz : foo` or even `foo.bar ? foo.bar.baz :
>> foo`. All three seem at least somewhat reasonable, and definitely
>> *believable* as an interpretation!
>>
>> ~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: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

[Michael J. Ryan]

With the promise.all, would each item in the iterable be an async function
(or function returning a promise)?  I mean, I'm presuming the point is to
not have every item execute at the same time.

-- 

Michael J. Ryan
Website: https://www.tracker1.info/
Email: track...@gmail.com
Mobile: 480-270-4509


On Fri, Sep 6, 2019 at 12:04 PM Cyril Auburtin 
wrote:

> It could be probably added as a `Promise.all(iterable, concurrency?)`
>
> Some existing implementations:
> - http://bluebirdjs.com/docs/api/promise.map.html
> - https://caolan.github.io/async/v3/docs.html#mapLimit
> - I tried to write one:
> https://github.com/caub/misc/blob/master/utils/promise-concurrent.js
>
> On Fri, Sep 6, 2019 at 8:33 PM Tom Boutell  wrote:
>
>> I am more interested in syntax two than syntax one, which I felt should
>> probably be included for completeness. But hey, as you say, maybe not since
>> unguarded concurrency is indeed usually a mistake.
>>
>> Taken on its own, do you have an objection to `for (item of items
>> concurrency 5) { ... }`?
>>
>>
>> On Fri, Sep 6, 2019 at 1:46 PM C. Scott Ananian 
>> wrote:
>>
>>> The current way to write what you want is:
>>>
>>> await Promise.all(itemsCursor.map(item => db.insert(item));
>>>
>>> or
>>>
>>> await Promise.all(itemsCursor.map(Promise.guard(5, item =>
>>> db.insert(item;
>>>
>>> if you are using a library like `prfun` (
>>> https://github.com/cscott/prfun#promiseguardfunctionnumber-condition-function-fn--function
>>> ).
>>>
>>> I'm not sure adding a new parallel loop construct is an obvious
>>> improvement on this, especially since unguarded concurrent execution is
>>> usually a mistake (can cause memory requirements to blow up), as you point
>>> out yourself.
>>>
>>> I'd be more in favor of new syntax if it was integrated with a
>>> work-stealing mechanism, since (a) that can't as easily be done in a
>>> library function (you need access to the entire set of runnable tasks, not
>>> just the ones created in this loop), and (b) is more likely to be
>>> correct/fast by default and not lead to subtle resource-exhaustion problems.
>>>   --scott
>>>
>>> On Fri, Sep 6, 2019 at 12:40 PM Tom Boutell 
>>> wrote:
>>>
>>>> *Specifying concurrency for "for...of" loops potentially containing
>>>> "await" statements in the loop body*
>>>>
>>>> In the async/await era, I see most developers using the async and await
>>>> keywords in 90% of situations, shifting to "Promise.all" or the bluebird
>>>> library only to cope with concurrency issues.
>>>>
>>>> The most common case in my experience is the need to admit a manageable
>>>> level of parallelism when iterating a large array (or iterator, see the
>>>> final section) and performing asynchronous work on each item. Unlimited
>>>> concurrency (Promise.all) tends to overwhelm backends involved in a way
>>>> that confuses developers as to what is happening. Bluebird's "Promise.map"
>>>> permits concurrency to be specified, which is great, but requires pulling
>>>> in a library and switching of mental gears ("OK right, these async
>>>> functions return promises," etc).
>>>>
>>>> To build on the friendliness of async/await, I propose these two
>>>> syntaxes be accepted:
>>>>
>>>> SYNTAX ONE
>>>>
>>>> ```js
>>>> for (item of items concurrent) {
>>>>   // db.insert is an async function
>>>>   await db.insert(item);
>>>> }
>>>> ```
>>>>
>>>> In Syntax One, all loop bodies commence concurrently (see below for the
>>>> definition of "concurrently" with regard to async). If an exception is not
>>>> caught inside the loop, it is thrown beyond the loop, and all exceptions
>>>> subsequently thrown by concurrently executing loop bodies are discarded
>>>> (like Promise.all).
>>>>
>>>> *While I feel that unlimited concurrency is usually a mistake in a
>>>> situation where you have an array of items of unpredictable number, it
>>>> seems odd not to have a syntax for this case, and "concurrency 0" seems
>>>> clunky.*
>>>>
>>>> SYNTAX TWO
>>>>
>>>> ```js
>>>> for (item of items concurrency 5) {
>>>>   // db.insert is an asy

Re: Optional chaining syntax but with the "mice" operator ?

[Michael Luder-Rosefield]

Another pattern it could be useful in is with, say, nosql dbs where
something might be an object or id reference:

```
const fooId = foo
wrote:

> Another use case that I believe will be common is the following one:
>
> ```js
> // current state of the art
> const result = dbQuery(data)?.rows ?? 'did it just failed or what?';
>
> // VS the "mice operator"
> const result = dbQuery(data)
> // if it was rows
> if (Array.isArray(result))
>   console.log(result);
> else if (result instanceof Error)
>   console.error(result.message);
> else
>   console.warn(`unexpected result: ${result}`);
> ```
>
> Ideally, the "mice" should grant chaining up to its latest presence, but I
> wouldn't know right now how to reference to it ...
>
> ```js
> // if no ?? is needed, this might work
> const result = dbQuery(data)
> // if ?? is needed, no idea how to back-reference the latest successfull
> "mice" result
> ```
>
>
>
>
> On Thu, Sep 5, 2019 at 11:44 PM Tab Atkins Jr. 
> wrote:
>
>> On Thu, Sep 5, 2019 at 2:39 PM Andrea Giammarchi
>>  wrote:
>> >
>> > This is basically a solution to a common problem we have these days,
>> where modules published in the wild might have a `default` property, to
>> support ESM logic, or not.
>> >
>> > ```js
>> > // current optional chaining logic
>> > const imported = exported?.default ?? exported;
>> >
>> > // my "mice operator" proposal
>> > const imported = exported> > ```
>> >
>> > Semantically speaking, not only `> also points at its previous value in case the chaining didn't work.
>> >
>> > Beside the basic example, the "mice operator" might save CPU cycles
>> when it comes to involving more complex expressions, i.e.
>> >
>> > ```js
>> > // current "solution"
>> > const thing = require('thing')?.default ?? require('thing');
>> >
>> > // mice operator
>> > const thing = require('thing')> > ```
>> >
>> > This is also easily tranpilable, so kinda a no-brainer for modern dev
>> tools to bring in.
>> >
>> > TL;DR specially for cases where an accessed property should fallback to
>> its source, this operator might save both typing and CPU time whenever it's
>> needed.
>>
>> I find it a rather curious pattern, that I'd never seen before! Is it
>> used in anything besides this ESM-compat thing you're talking about?
>>
>> (Saving CPU cycles is not a convincing argument; it's trivial to write
>> such a line over two declarations and avoid any expensive
>> recomputations.)
>>
>> ~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: Moving forward with function decorators

[Michael Luder-Rosefield]

I don't see any mention of class/object shorthand methods; would these be
trivial, do you think?

```
class FooClass {
  @dec1 @dec2
  bar () { }
}

const fooObj = {
 @dec1 @dec2
  bar () { }
}
```
--
Dammit babies, you've got to be kind.


On Wed, 4 Sep 2019 at 11:49, Андрей Губанов 
wrote:

> Here I described my thoughts about this topic
> https://github.com/finom/function-decorators-proposal. The main idea of
> moving forward with function decorators is to make them behave like there
> were defined and wrapped by another function, not more, and get rid of any
> hoisting when they're used.
>
> Function expression and arrow functions
>
> const foo = @decorator1 @decorator2 function bar() { return "Hello" }
> // Will become:
> const foo = decorate([decorator1, decorator2], function bar() { return 
> "Hello" });
>
> And
>
> const foo = @decorator1 @decorator2 () => "Hello"
> // Will become:
> const foo = decorate([decorator1, decorator2], () => "Hello");
>
>
> Function
> declarations
>
> And this is the most important. I propose to make a decorated function
> declaration behave as let definition.
>
> @decorator1 @decorator2 function foo() { return "Hello" }
> // Will become:
> let foo = decorate([decorator1, decorator2], function foo() { return "Hello" 
> }); // no hoisting!
>
> ___
> 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: globalThis.assertOrThrow

[Michael Haufe]

https://esdiscuss.org/topic/native-assertions

From: es-discuss  On Behalf Of kai zhu
Sent: Saturday, August 31, 2019 2:22 PM
To: es-discuss 
Subject: globalThis.assertOrThrow

having a universal assert function (similar to nodejs' assert builtin) might be 
useful.  it could be name "assertOrThrow" for web-compat.

this would simplify writing common-case "throwaway" error-handling behavior in 
both browsers and nodejs:

```js
// naive polyfill
globalThis.assertOrThrow = globalThis.assertOrThrow || function (passed, 
message) {
/*
 * this function will throw error  if  is falsy
 */
if (passed) {
return;
}
throw (
typeof message === "object" && message
? message
: new Error(message)
}
};

localforage.setItem("foo", "bar", function (err, data) {
// validate no err occurred
// this one-line statement makes writing test-coverage less tedious
assertOrThrow(!err, err);
...
});
```

-kai

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

Re: [Proposal] Optional chaining

[Michael Luder-Rosefield]

Another similar thing I've used is with String interpolation; if you use a
similar pattern, e.g.,

``` `$[items.length} item${items.length !== 1 ? 's' : ''} in collection` ```

When you want to conditionally add either some text, or nothing at all, you
are forced to use the ternary with an empty string, or some workaround. In
terms of a proposal, the first thing I think we need to know is: can the
interpreter detect that it's in a template literal, in the same manner as
it detects ?...  being in an object/array declaration context?
--
Dammit babies, you've got to be kind.


On Fri, 23 Aug 2019 at 02:01, Beknar Askarov 
wrote:

> Problem
>
> Spreading is great! It contributes towards "declerativity" of the language
> and reduces verbosity. I see one more feature to add to improve it.
>
> Consider following
>
> [
>   1,
>   condition && 2,
>   condition && 3,
>   4,
> ].filter(Boolean) // filtering needed to remove falsy values
> // Results in
> [1, 2, 3, 4] // if condition is `truthy`// and
> [1, 4] // if not truthy.
>
> Another way to achieve the same result without the need of filtering after
>
> [
>   1,
>...(condition ? [2, 3] : []), // note extra [] in the end, to avoid errors
>   4,
> ]
>
> Similar pattern with objects
>
> {
>   ...(condition ? { foo: 'bar' } : {}), // extra {}
> }
>
> Another pattern is when condition is the object itself, when it is known
> that type is one or falsy
>
> [
>   item1,
>   item2,
>   ...(itemsOrNull || []) // extra []
> ]
>
> Similar for objects
>
> {
>   ...(obj || {}), // extra {}
> }
>
> I see these patterns appearing very often. And these are cleanest examples
> I have seen so far.
> ProposalOptional spreadingWith condition
>
> // Arrays
> [
>   1,
>   ?...(condition && [2, 3]), // no extras:)
>   3,
> ]// Objects
> {
>   ?...(condition && { foo: 'bar' }) // no extras:)
> }
>
> When condition is the object
>
> [
>   item1,
>   item2,
>   ?...itemsOrNull // no extras at all:) even (...)
> ]
>
> These look nicer and can be good for performance since (?...), since no
> cleanup is needed after to remove falsy values or extra spreading even when
> it is not needed.
>
> Looks intuitive (since: https://github.com/tc39/proposal-optional-chaining
> )
> Plays nice with typeings.
>
> What do you think? https://es.discourse.group/t/optional-spreading/93
> ___
> 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: Modulo Operator %%

[Michael Haufe]

Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote:

> FWIW another disadvantage is that operators cannot be polyfilled, so it'll 
> take forever for those not using transpilers to adopt these, while having a 
> `Math,mod` would work right away


With such an approach there is risk of another ‘smooshgate’ [1][2]. There is 
nothing stopping those developers from using a function anyway to bridge the 
gap if they can’t or won’t use a compiler. This is already the current state of 
affairs.

[1] https://developers.google.com/web/updates/2018/03/smooshgate
[2] https://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/

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

RE: Modulo Operator %%

[Michael Haufe]

On 8/14/19 7:50 PM, Waldemar Horwat wrote:

> And I'm saying that's potentially problematic because it changes the meaning 
> of existing programs that happen to use "mod" as a variable name.  The above 
> is one example that would turn a let statement into a mod expression.  Here's 
> another example:
> 
> x = 4
> mod(foo)


Potentially yes and surely there is a yacc definition where one could check to 
be certain? Regardless, let's assume there is or that workarounds to guarantee 
infixity are not worth the complication ([no LineTerminator here] usage).

We know that syntax is the last bastion of language luddites, so it's best not 
to linger on something which was not my main concern. I am more interested in 
maintaining the duality of the operators over how they are represented (within 
reason). Thus, if '%%' is what is preferable, then '\\' would be the partner.

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

Re: Modulo Operator %%

[Michael Luder-Rosefield]

Is there any way we can add function/operator equivalence to the language?
Perhaps some kind of 'operators' global object with symbol fields matching
operator string to functions/constraints?
--
Dammit babies, you've got to be kind.


On Thu, 15 Aug 2019 at 08:47, Andrea Giammarchi 
wrote:

> FWIW another disadvantage is that operators cannot be polyfilled, so it'll
> take forever for those not using transpilers to adopt these, while having a
> `Math,mod` would work right away
>
> On Thu, Aug 15, 2019 at 8:40 AM Claude Pache 
> wrote:
>
>>
>>
>> Le 12 août 2019 à 22:00, Matthew Morgan  a écrit
>> :
>>
>> JS needs a modulo operator. It currently has the remainder operator `%`
>> which works in most cases except for negative values. I believe the the
>> `%%` would work great and be easy to remember.
>>
>> let x = (-13) %% 64;
>> is equivalent to
>> let x = ((-13 % 64) + 64) % 64;
>>
>>
>> Is there a strong advantage of an `%%` operator over a `Math.mod()`
>> function? There is the precedent of the `**` operator implemented as
>> alternative of `Math.pow()` few years ago. It would be interesting to hear
>> the feedback of those that use regularly powers, whether the benefit was
>> clear (personally, I almost never use either `Math.pow()` or `**`, so that
>> I can’t say anything).
>>
>> At least one disadvantage of an operator over a function, is that you
>> have to think about precedence. The problem is exacerbated in JS, because
>> (following some other languages) the unary minus has an uncanny high
>> precedence level, confusingly very different than the one of the binary
>> minus; so that, after having designed `**`, it was realised at the last
>> minute that `-a**b` would be dumbly interpreted as `(-a)**b` instead of
>> `-(a**b)` or `0-a**b`, as anybody who would be likely to actually use the
>> operator would expect. (That particular issue was resolved in a hurry by
>> making the parenthesis-left form a syntax error.)
>>
>> —Claude
>>
>> ___
>> 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: Modulo Operator %%

[Michael Haufe]

On 8/13/19 7:27 AM, Michael Haufe wrote:
> I would prefer the syntax be ‘a mod b’ consistent with my wishlist item:

On 8/13/19 9:12 PM, Waldemar Horwat wrote:
> This can bring up various syntactic troubles.  What does the following do?
>
> let mod
> +3
>
> Is it calling the mod operator on the variable named "let" and +3?  Or is it 
> defining a variable named "mod" with no initializer, followed by an 
> expression?

I can't declare 'let' or 'var' as variable names, but even if I could (Say 
non-strict mode or ES3) that form would be a VariableDeclaration followed by an 
ExpressionStatement.

The proposed grammar extension is:

MultiplicativeOperator: one of
* / % div mod

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

RE: Modulo Operator %%

[Michael Haufe]

Related:

https://esdiscuss.org/notes/2018-01-24#13vd-operator-overloading-for-stage-1

I don’t see anything newer than this

From: es-discuss  On Behalf Of Cyril Auburtin
Sent: Tuesday, August 13, 2019 5:07 AM
Cc: es-discuss 
Subject: Re: Modulo Operator %%

agreed, let's make a proposal

On Tue, Aug 13, 2019 at 12:06 AM kdex mailto:k...@kdex.de>> wrote:
I would welcome such an operator as well. I find myself implementing a `mod`
function from time to time, expressing it in terms of the remainder operator.

As for syntax, I don't see `%%` posing any syntactical ambiguities, so I'll
second it.

On Monday, August 12, 2019 10:00:09 PM CEST Matthew Morgan wrote:
> JS needs a modulo operator. It currently has the remainder operator `%`
> which works in most cases except for negative values. I believe the the
> `%%` would work great and be easy to remember.
>
> let x = (-13) %% 64;
> is equivalent to
> let x = ((-13 % 64) + 64) % 64;___
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: Modulo Operator %%

[Michael Haufe]

I would prefer the syntax be ‘a mod b’ consistent with my wishlist item:




In regards to semantics:





From: es-discuss  On Behalf Of Cyril Auburtin
Sent: Tuesday, August 13, 2019 5:07 AM
Cc: es-discuss 
Subject: Re: Modulo Operator %%

agreed, let's make a proposal

On Tue, Aug 13, 2019 at 12:06 AM kdex mailto:k...@kdex.de>> wrote:
I would welcome such an operator as well. I find myself implementing a `mod`
function from time to time, expressing it in terms of the remainder operator.

As for syntax, I don't see `%%` posing any syntactical ambiguities, so I'll
second it.

On Monday, August 12, 2019 10:00:09 PM CEST Matthew Morgan wrote:
> JS needs a modulo operator. It currently has the remainder operator `%`
> which works in most cases except for negative values. I believe the the
> `%%` would work great and be easy to remember.
>
> let x = (-13) %% 64;
> is equivalent to
> let x = ((-13 % 64) + 64) % 64;___
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: Typeof Trap

[Michael Haufe]

Congratz. It was document.all. 

"In case you're wondering, I've never seen anyone return or store 
`document.all` ever."

Before W3C standard you could (and some people did):

function elements() {
if(document.all) {
return document.all
} else if(document.layers) {
return document.layers
} else {
throw "You must use IE4+ or NS 4.7!"
}
}

This is actually the wrong way to use document.layers, but it was not uncommon 
to see. Later when the W3C was standardizing, you managed the three pathways by 
passing the id to the function.

You can see examples of this on comp.lang.javascript, and through a search 
engine by looking for "return document.all" or "return document.layers". There 
are also some legacy books showing the practice.

/Michael


-Original Message-
From: Isiah Meadows  
Sent: Saturday, July 27, 2019 4:42 PM
To: Michael Haufe 
Cc: Jordan Harband ; es-discuss@mozilla.org
Subject: Re: Proposal: Typeof Trap

`document.all`, and that's only required for web browsers to implement
- it's in Annex B. Some newer JS engines targeting non-browser platforms (like 
Moddable's XS and I believe Nashorn as well) don't even implement it, and it 
leads to a slightly simpler runtime.

And it's only there thanks to a bunch of people relying on `if
(document.all) doSomething()` for detecting legacy crap while others at the 
same time just assuming it's there without checking for it first, almost always 
on ancient web pages. Oh, and people were also calling it via 
`document.all(nameOrIndex)` instead of `document.all[nameOrIndex]`, so the HTML 
spec also has it implementing `[[Call]]`.

- HTML spec: 
https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#the-htmlallcollection-interface
- ES spec: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot

In case you're wondering, I've never seen anyone return or store `document.all` 
ever.

-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com


On Sat, Jul 27, 2019 at 5:20 PM Michael Haufe  wrote:
>
> More than one case:
>
>
>
> 
>
> var foo = f()
>
> typeof foo // object
>
> foo instanceof Object // false
>
>
>
> var bar = g()
>
> typeof bar //undefined
>
> bar instanceof Object //true
>
> bar() //
>
> 
>
>
>
> You could probably guess what the value of foo is. Can you guess what the 
> second is in any useful way?
>
>
>
> From: Jordan Harband 
> Sent: Saturday, July 27, 2019 3:56 PM
> To: Michael Haufe 
> Cc: es-discuss@mozilla.org
> Subject: Re: Proposal: Typeof Trap
>
>
>
> With something that while unintuitive in one case, is eternally robust and 
> reliable.
>
>
>
> If you want extensibility, define Symbol.toStringTag on your objects.
>
>
>
> On Sat, Jul 27, 2019 at 1:23 PM Michael Haufe  
> wrote:
>
> If it's unfixably broken[1], non-extensible, excessively vague, and 
> non-orthogonal, where does that leave you?
>
>
>
> [1] <https://twitter.com/BrendanEich/status/798317702775324672>
>
>
>
> From: Jordan Harband 
> Sent: Saturday, July 27, 2019 3:00 PM
> To: Michael Haufe 
> Cc: ViliusCreator ; 
> es-discuss@mozilla.org
> Subject: Re: Proposal: Typeof Trap
>
>
>
> Those two PRs are about removing implementation-defined behavior from 
> `typeof`, making it *more* reliable - there is no trend away from using and 
> relying on `typeof`, full stop.
>
>
>
> `Symbol.hasInstance` is a part of why `instanceof` is actually unreliable - 
> because user code can hook into it. It would be a massive loss imo if 
> `typeof` lost its bulletproof status by adding a user hook.
>
>
>
> On Sat, Jul 27, 2019 at 12:37 PM Michael Haufe  
> wrote:
>
> The trend seems to be to rely on typeof less and less as time passes:
>
>
>
> From the  March 2019 Agenda 
> <https://github.com/tc39/agendas/blob/274e49412c09f81a0a82f386e6eead481c69adad/2019/03.md>:
>
>
>
> “Implementation-defined typeof still necessary?” 
> <https://github.com/tc39/ecma262/issues/1440>
>
> “Normative: Remove implementation-defined typeof behavior” 
> <https://github.com/tc39/ecma262/pull/1441>
>
>
>
>
>
> The only real discussion around this I can find is from a related proposal 
> from Brendan Eich a few years ago:
>
>
>
> https://esdiscuss.org/topic/typeof-extensibility-building-on-my-value-
> objects-slides-from-thursday-s-tc39-meeting
>
>
>
>
>
>
>
> From: ViliusCreator 
> Sent: Saturday, July 27, 2019 2:04 PM
> To: Michael Haufe 
> Subject: RE: Proposal: Typeof Trap
>
>
>
> Yes, but it traps `typeof `, not `instanceof`. There’s difference there.
>
> ___
> 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: Typeof Trap

[Michael Haufe]

More than one case:


var foo = f()
typeof foo // object
foo instanceof Object // false

var bar = g()
typeof bar //undefined
bar instanceof Object //true
bar() //


You could probably guess what the value of foo is. Can you guess what the 
second is in any useful way?

From: Jordan Harband 
Sent: Saturday, July 27, 2019 3:56 PM
To: Michael Haufe 
Cc: es-discuss@mozilla.org
Subject: Re: Proposal: Typeof Trap

With something that while unintuitive in one case, is eternally robust and 
reliable.

If you want extensibility, define Symbol.toStringTag on your objects.

On Sat, Jul 27, 2019 at 1:23 PM Michael Haufe 
mailto:t...@thenewobjective.com>> wrote:
If it's unfixably broken[1], non-extensible, excessively vague, and 
non-orthogonal, where does that leave you?

[1] <https://twitter.com/BrendanEich/status/798317702775324672>

From: Jordan Harband mailto:ljh...@gmail.com>>
Sent: Saturday, July 27, 2019 3:00 PM
To: Michael Haufe mailto:t...@thenewobjective.com>>
Cc: ViliusCreator 
mailto:viliuskubilius...@gmail.com>>; 
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
Subject: Re: Proposal: Typeof Trap

Those two PRs are about removing implementation-defined behavior from `typeof`, 
making it *more* reliable - there is no trend away from using and relying on 
`typeof`, full stop.

`Symbol.hasInstance` is a part of why `instanceof` is actually unreliable - 
because user code can hook into it. It would be a massive loss imo if `typeof` 
lost its bulletproof status by adding a user hook.

On Sat, Jul 27, 2019 at 12:37 PM Michael Haufe 
mailto:t...@thenewobjective.com>> wrote:
The trend seems to be to rely on typeof less and less as time passes:

From the  March 2019 Agenda 
<https://github.com/tc39/agendas/blob/274e49412c09f81a0a82f386e6eead481c69adad/2019/03.md>:

“Implementation-defined typeof still necessary?” 
<https://github.com/tc39/ecma262/issues/1440>
“Normative: Remove implementation-defined typeof behavior” 
<https://github.com/tc39/ecma262/pull/1441>


The only real discussion around this I can find is from a related proposal from 
Brendan Eich a few years ago:

https://esdiscuss.org/topic/typeof-extensibility-building-on-my-value-objects-slides-from-thursday-s-tc39-meeting



From: ViliusCreator 
mailto:viliuskubilius...@gmail.com>>
Sent: Saturday, July 27, 2019 2:04 PM
To: Michael Haufe mailto:t...@thenewobjective.com>>
Subject: RE: Proposal: Typeof Trap

Yes, but it traps `typeof `, not `instanceof`. There’s difference there.
___
es-discuss mailing list
es-discuss@mozilla.org<mailto: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: Typeof Trap

[Michael Haufe]

If it's unfixably broken[1], non-extensible, excessively vague, and 
non-orthogonal, where does that leave you?

[1] <https://twitter.com/BrendanEich/status/798317702775324672>

From: Jordan Harband 
Sent: Saturday, July 27, 2019 3:00 PM
To: Michael Haufe 
Cc: ViliusCreator ; es-discuss@mozilla.org
Subject: Re: Proposal: Typeof Trap

Those two PRs are about removing implementation-defined behavior from `typeof`, 
making it *more* reliable - there is no trend away from using and relying on 
`typeof`, full stop.

`Symbol.hasInstance` is a part of why `instanceof` is actually unreliable - 
because user code can hook into it. It would be a massive loss imo if `typeof` 
lost its bulletproof status by adding a user hook.

On Sat, Jul 27, 2019 at 12:37 PM Michael Haufe 
mailto:t...@thenewobjective.com>> wrote:
The trend seems to be to rely on typeof less and less as time passes:

From the  March 2019 Agenda 
<https://github.com/tc39/agendas/blob/274e49412c09f81a0a82f386e6eead481c69adad/2019/03.md>:

“Implementation-defined typeof still necessary?” 
<https://github.com/tc39/ecma262/issues/1440>
“Normative: Remove implementation-defined typeof behavior” 
<https://github.com/tc39/ecma262/pull/1441>


The only real discussion around this I can find is from a related proposal from 
Brendan Eich a few years ago:

https://esdiscuss.org/topic/typeof-extensibility-building-on-my-value-objects-slides-from-thursday-s-tc39-meeting



From: ViliusCreator 
mailto:viliuskubilius...@gmail.com>>
Sent: Saturday, July 27, 2019 2:04 PM
To: Michael Haufe mailto:t...@thenewobjective.com>>
Subject: RE: Proposal: Typeof Trap

Yes, but it traps `typeof `, not `instanceof`. There’s difference there.
___
es-discuss mailing list
es-discuss@mozilla.org<mailto: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: Typeof Trap

[Michael Haufe]

Symbol.hasInstance exists

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/hasInstance

/Michael

From: es-discuss  On Behalf Of ViliusCreator
Sent: Saturday, July 27, 2019 1:58 PM
To: es-discuss@mozilla.org
Subject: Proposal: Typeof Trap

Proxy’s typeof trap. Example:
```js
class ClassA {}
const proxyHandler = {
type(target) {
return target instanceof ClassA ? `object_a` : typeof target
}
}
const instanceA = new ClassA
const proxyA = new Proxy(instanceA, proxyHandler)
typeof proxyA // ‘object_a’
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Proposal: Typeof Trap

[Michael Haufe]

The trend seems to be to rely on typeof less and less as time passes:

From the  March 2019 Agenda 
<https://github.com/tc39/agendas/blob/274e49412c09f81a0a82f386e6eead481c69adad/2019/03.md>:

“Implementation-defined typeof still necessary?” 
<https://github.com/tc39/ecma262/issues/1440>
“Normative: Remove implementation-defined typeof behavior” 
<https://github.com/tc39/ecma262/pull/1441>


The only real discussion around this I can find is from a related proposal from 
Brendan Eich a few years ago:

https://esdiscuss.org/topic/typeof-extensibility-building-on-my-value-objects-slides-from-thursday-s-tc39-meeting



From: ViliusCreator 
Sent: Saturday, July 27, 2019 2:04 PM
To: Michael Haufe 
Subject: RE: Proposal: Typeof Trap

Yes, but it traps `typeof `, not `instanceof`. There’s difference there.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Fwd: The world is broken, will you help me fix it?

[Michael Lewis]

-- Forwarded message -
From: Michael Lewis 
Date: Fri, Jul 26, 2019 at 2:34 PM
Subject: The world is broken, will you help me fix it?
To: , , ,
, , <
sc...@foundersfund.com>, , ,
, , <
inquir...@eric-weinstein.net>


Hello world,

I have a vision.  It is the Truth.

[image: image.png]

*The short version*: we need better design, development, data, versioning,
collaboration, management, and decision making tools.  If we rebuild the
software design and development experience from the bottom up, we'll be
able to create 10x better software, 10x faster, 10x cheaper.


*Michael Lewis*‏  (me)@mlew42 <https://twitter.com/mlew42>
> More
>
> @peterthiel <https://twitter.com/peterthiel> just watched your chat with
> @EricRWeinstein <https://twitter.com/EricRWeinstein>. The world (tech
> (web, software, cad/cam), gov, edu) is broken. I know how to fix it, but
> I'm suffocating (unemployment, student debt, depression), and on many days,
> I'd rather kill myself than continue the struggle
> 10:57 AM - 26 Jul 2019
>
https://twitter.com/mlew42/status/1154782897242550274
>

It's doubtful he will ever see the tweet.

In the "podcast," Peter Thiel and Eric Weinstein make the case that *we're
not actually doing a good job*, despite what some would claim.  It's hard
to understand, because we're so hyper-competitive.  Competitively
incompetent.  What cannot be argued, is that *we can do better*.

*The Long Vision*

We need better *decision making software*.  Email is garbage.  We need a
tool to identify all options, discuss, rank, plan and execute.  Something
like Reddit, that results in real productivity, government decisions, and
allocating resources.  Plan, then build.  Design, then develop.  CAD and
CAM.

There's no single recipe for what a "decision making system" would look
like.  Maybe it's just a Google doc.  Maybe it looks like Reddit.  Or maybe
it's like WordPress, where you can install plugins?  We need a solid
platform (like a webOS) where it's relatively easy to build new features.

I could try to speak more to the absolute mess that currently exists.  Go
to Product Hunt, and start counting.  "Ridiculous" hardly explains it.

There are 700 web-based project management platforms listed on capterra.com.
And not a single one of them is doing a great job.  Every single web app in
the world has to build its own user auth, database, user interface,
workflows, features, etc.  This is sort of like having a separate DMV for
every state in the USA.  Competitive incompetence.


*webOS*

Hold onto your pants:  We need to take all our software, and rebuild it on
a single tech stack.  Enter the *webOS*.  It's like Webflow + WordPress +
Wikipedia + Google + Facebook + Twitter + LinkedIn + YouTube + Khan
Academy + Windows + Android + Gmail + Reddit + 

Rewriting so many sophisticated systems wouldn't be easy.  Unless you
realize that they're all basically the same thing:  a database of users,
posts, and apps.

The webOS has to be a hybrid of open and closed source, with advanced
licensing controls.  It must be monetized, so people are incentivized to
contribute (open source lacks this).  There needs to be clear licensing
terms, and advanced licensing controls, so developers can license their
code on a per user per month basis, for example.

A real Operating System builds all the critical productivity features (like
threaded discussions, project management, "email", version control,
collaboration, UI, plugins, etc) directly into the operating system itself,
so that it's automatically integrated throughout every app.


*gitOS*

The core of all of this, is the file system.  The data.  The meat and
potatoes.  Git is an incredible technology (that powers GitHub), is cross
platform, handles versioning, branching, merging, conflict resolution,
etc.  This technology should be built into every database, document,
design, image, email, application, film, etc.  Someday soon, *every person
who uses a computer will be an expert with versioning.  *But git, as a
command line tool, is insanely hard to use.  We need a git UI.  Let's call
it the *gitOS*.  This will provide an incredibly powerful feature to every
application built with the *webOS*.


*node OS*

Ever since I jumped ship as a WordPress developer, I've been waiting for
node.js to catch up.  It hasn't.  JavaScript and node.js should have
replaced Windows by now.  Show me a WordPress competitor built on node.js,
and you'll find a couple (sails, keystone, gatsby?).  There are literally a
million competitors in this field (SquareSpace, Weebly, Wix, etc).  Why
can't anyone fix this problem?  Node.js is capable of so much more:*
nodeOS.*

[image: image.png]

Can you help me?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: A way to fire logic at the end of completion of the current class method (regardless of super call order).

[Michael Haufe]

You should read the original message I quoted and the related thread:

https://mail.mozilla.org/pipermail/es-discuss/2019-February/thread.html#52279

Assuming what people understand is a recipe for disappointment in my 
experience. Also, we should differentiate between “simple” and “simplistic”.

/Michael

From: Naveen Chawla 
Sent: Friday, July 19, 2019 3:51 AM
To: Michael Haufe 
Cc: j...@trusktr.io; es-discuss 
Subject: Re: A way to fire logic at the end of completion of the current class 
method (regardless of super call order).

Is this a problem in the real world? Most people understand that simply 
overriding methods can break functionality. Therefore, doesn't the simple 
approach I gave suffice for the requirement in at least most cases? Are you 
able to describe a scenario in which we really need to protect people who are 
overriding a method from breaking functionality that they might not even expect 
to occur after they've overridden it?

On Fri, 19 Jul 2019 at 09:32, Michael Haufe 
mailto:t...@thenewobjective.com>> wrote:
Assuming your base class:


class Base {
methodWIthAfter(){
method()
after()
}
}


If I override the method, there is no guarantee that I called 
`super.methodWithAfter()`, so `after()` is never executed.


class A extends Base {
methodWithAfter() {
method2()
}
}


Additionally, requiring me to call ` super.methodWithAfter()` is an 
Anti-Pattern: https://en.wikipedia.org/wiki/Call_super

/Michael

From: Naveen Chawla mailto:naveen.c...@gmail.com>>
Sent: Friday, July 19, 2019 3:24 AM
To: Michael Haufe mailto:t...@thenewobjective.com>>
Cc: j...@trusktr.io<mailto:j...@trusktr.io>; es-discuss 
mailto:es-discuss@mozilla.org>>
Subject: Re: A way to fire logic at the end of completion of the current class 
method (regardless of super call order).

Can anyone tell me what's wrong with a really simple approach? Wherever you are 
calling method(), just call methodWithAfter():

//in base class
methodWithAfter(){
method();
after()
}

What am I missing, guys?

On Fri, 19 Jul 2019 at 07:43, Michael Haufe 
mailto:t...@thenewobjective.com>> wrote:
Revisiting this topic: why is the Template Method pattern not acceptable to 
accomplish this?


class Base {
constructor() {
this._beforeAction()
this._action()
this._afterAction()
}
_beforeAction(){
console.log(`Base._beforeAction()`)
}
_action(){
console.log(`Base._action()`)
}
_afterAction(){
console.log(`Base._afterAction()`)
}
}

class A extends Base {
_action(){
console.log(`A._action()`)
}
}

let a = new A()
// console reads:
// > Base._beforeAction()
// > A._action()
// > Base._afterAction()


/Michael
-

Monday, February 11, 2019 10:34 PM Michael Haufe 
mailto:t...@thenewobjective.com>> wrote:

> You can use a Proxy in the base class:
>
> 
> let handlerExample = {
> get(target, prop) {
> let feature = target[prop]
> return feature instanceof Function ?
> function () {
> console.log('Before call');
> let result = feature.apply(this, arguments)
> console.log('After call');
> return result
> }
> : feature
> }
> }
>
> class Base {
> constructor() {
> return new Proxy(this, handlerExample)
>  }
> m1() { return "m1" }
> }
>
> class Sub extends Base {
> m1() { return `override ${super.m1()}` }
> m2() { return `m2` }
> }
>
> let base = new Base()
> console.log(base.m1())
>
> let sub = new Sub()
> console.log(sub.m1())
> console.log(sub.m2())
> 
>
> /Michael


On Fri, Feb 8, 2019 at 1:22 AM #!/JoePea 
mailto:j...@trusktr.io>> wrote:

 > I many times find myself in cases where a base class wants to ensure that 
 > logic is always fired after the current method's execution, so that for 
 > example no matter in which order sub classes call the `super` method, the 
 > `super` method can still guarantee that logic fires after the whole stack of 
 > the same method in the class hierarchy.

> So what I can do now is use `Promise.resolve().then(() => { ... })` to 
> schedule that logic for later, that way all the invocations of a `foo` method 
> along the class hierarchy have all fired. But this means that other code can 
> also fire before the next microtask.

> Is there some way to do it? If not, I wonder if some language feature for 
> doing it would be possible?
___
es-discuss mailing list
es-discuss@mozilla.org<mailto: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: A way to fire logic at the end of completion of the current class method (regardless of super call order).

[Michael Haufe]

Assuming your base class:


class Base {
methodWIthAfter(){
method()
after()
}
}


If I override the method, there is no guarantee that I called 
`super.methodWithAfter()`, so `after()` is never executed.


class A extends Base {
methodWithAfter() {
method2()
}
}


Additionally, requiring me to call ` super.methodWithAfter()` is an 
Anti-Pattern: https://en.wikipedia.org/wiki/Call_super

/Michael

From: Naveen Chawla 
Sent: Friday, July 19, 2019 3:24 AM
To: Michael Haufe 
Cc: j...@trusktr.io; es-discuss 
Subject: Re: A way to fire logic at the end of completion of the current class 
method (regardless of super call order).

Can anyone tell me what's wrong with a really simple approach? Wherever you are 
calling method(), just call methodWithAfter():

//in base class
methodWithAfter(){
method();
after()
}

What am I missing, guys?

On Fri, 19 Jul 2019 at 07:43, Michael Haufe 
mailto:t...@thenewobjective.com>> wrote:
Revisiting this topic: why is the Template Method pattern not acceptable to 
accomplish this?


class Base {
constructor() {
this._beforeAction()
this._action()
this._afterAction()
}
_beforeAction(){
console.log(`Base._beforeAction()`)
}
_action(){
console.log(`Base._action()`)
}
_afterAction(){
console.log(`Base._afterAction()`)
}
}

class A extends Base {
_action(){
console.log(`A._action()`)
}
}

let a = new A()
// console reads:
// > Base._beforeAction()
// > A._action()
// > Base._afterAction()


/Michael
-

Monday, February 11, 2019 10:34 PM Michael Haufe 
mailto:t...@thenewobjective.com>> wrote:

> You can use a Proxy in the base class:
>
> 
> let handlerExample = {
> get(target, prop) {
> let feature = target[prop]
> return feature instanceof Function ?
> function () {
> console.log('Before call');
> let result = feature.apply(this, arguments)
> console.log('After call');
> return result
> }
> : feature
> }
> }
>
> class Base {
> constructor() {
> return new Proxy(this, handlerExample)
>  }
> m1() { return "m1" }
> }
>
> class Sub extends Base {
> m1() { return `override ${super.m1()}` }
> m2() { return `m2` }
> }
>
> let base = new Base()
> console.log(base.m1())
>
> let sub = new Sub()
> console.log(sub.m1())
> console.log(sub.m2())
> 
>
> /Michael


On Fri, Feb 8, 2019 at 1:22 AM #!/JoePea 
mailto:j...@trusktr.io>> wrote:

 > I many times find myself in cases where a base class wants to ensure that 
 > logic is always fired after the current method's execution, so that for 
 > example no matter in which order sub classes call the `super` method, the 
 > `super` method can still guarantee that logic fires after the whole stack of 
 > the same method in the class hierarchy.

> So what I can do now is use `Promise.resolve().then(() => { ... })` to 
> schedule that logic for later, that way all the invocations of a `foo` method 
> along the class hierarchy have all fired. But this means that other code can 
> also fire before the next microtask.

> Is there some way to do it? If not, I wonder if some language feature for 
> doing it would be possible?
___
es-discuss mailing list
es-discuss@mozilla.org<mailto: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: A way to fire logic at the end of completion of the current class method (regardless of super call order).

[Michael Haufe]

Revisiting this topic: why is the Template Method pattern not acceptable to 
accomplish this?


class Base {
constructor() {
this._beforeAction()
this._action()
this._afterAction()
}
_beforeAction(){
console.log(`Base._beforeAction()`)
}
_action(){
console.log(`Base._action()`)
}
_afterAction(){
console.log(`Base._afterAction()`)
}
}

class A extends Base {
_action(){
console.log(`A._action()`)
}
}

let a = new A()
// console reads:
// > Base._beforeAction()
// > A._action()
// > Base._afterAction()


/Michael
-

Monday, February 11, 2019 10:34 PM Michael Haufe  
wrote:

> You can use a Proxy in the base class:
>
> 
> let handlerExample = {
> get(target, prop) {
> let feature = target[prop]
> return feature instanceof Function ?
> function () {
> console.log('Before call');
> let result = feature.apply(this, arguments)
> console.log('After call');
> return result
> }
> : feature
> }
> }
>
> class Base {
> constructor() {
> return new Proxy(this, handlerExample)
>  }
> m1() { return "m1" }
> }
>
> class Sub extends Base {
> m1() { return `override ${super.m1()}` }
> m2() { return `m2` }
> }
>
> let base = new Base()
> console.log(base.m1())
>
> let sub = new Sub()
> console.log(sub.m1())
> console.log(sub.m2())
> 
>
> /Michael


On Fri, Feb 8, 2019 at 1:22 AM #!/JoePea  wrote:

 > I many times find myself in cases where a base class wants to ensure that 
 > logic is always fired after the current method's execution, so that for 
 > example no matter in which order sub classes call the `super` method, the 
 > `super` method can still guarantee that logic fires after the whole stack of 
 > the same method in the class hierarchy.

> So what I can do now is use `Promise.resolve().then(() => { ... })` to 
> schedule that logic for later, that way all the invocations of a `foo` method 
> along the class hierarchy have all fired. But this means that other code can 
> also fire before the next microtask.

> Is there some way to do it? If not, I wonder if some language feature for 
> doing it would be possible?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Selector/Select Expression

[Michael Luder-Rosefield]

The more I read this proposal, the more I feel the ideal solution is a
preceding 'wildcard' character, to stand-in for a generic argument. If it
wasn't in (widespread!) use, I'd suggest an underscore: ```const f = _.prop
```

Since it is, though, we need another one. How about a double-colon, seeing
as it can represent property access on other languages? ```const f = ::prop
```, ```const g = ::[compProp] ```, ```const h =  ::?optProp ```

On Sun, 23 Jun 2019, 11:43 Simon Farrugia, 
wrote:

> I was expecting that someone brings up the brackets property accessor at
> some point.
> I would argue that there is a bit of syntactic inconsistency since usually
> when using the bracket accessors it is not preceded by a dot.
> ```
> const getEmail = user => user["contacts"].email; // No dot between user &
> ["contacts"].
> const getEmail = .["contacts"].email;
> ```
> Having said that, the currently proposed Optional Chaining operator
> (Stage 2)  does
> exactly that and more:
> ```
> obj?.prop   // optional static property access
> obj?.[expr] // optional dynamic property access
> func?.(...args) // optional function or method call
> ```
> So I'd say that there is consistency with what is currently being proposed.
>
> Regarding the Optional Chaining operator, which precedes the dot. How
> would that work?
>
> It would have to be something like this, if allowed.
> ```
>
> const getEmail = user => user?.contacts.email;
> const getEmail = ?.contacts.email;
>
> ```
>
> It does look odd at first, but it’s quite simple is you think about it. We
> are just omitting the initial part of the expression.
>
>
>
> More Examples with Optional Chaining operator:
>
> ```
>
> // With optional dynamic property access.
>
> const getUserEmail = user => user?.["contacts"].email;
> const getUserEmail = ?.["contacts"].email;
>
>
>
> // With optional function or method call.
>
> const getJohnsEmail = getUserContacts =>  getUserContacts
> ?.("John").email;
> const getJohnsEmail = ?.("john").email;
>
> ```
>
>
>
> The beauty of what is being proposed is that there is nothing new to learn
> or any new weird operator introduced.
>
> Any weirdness one might find with the expressions above will already have
> been introduced by the Optional Chaining operator.
>
> The only thing this does is to allow you to omit the initial (redundant)
> part of the expression.
>
>
> ___
> es-discuss mailing list
> 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

[Michael Luder-Rosefield]

I tried to see if I could do this in a single destructuring step, but here
is what happened:

```
var user = { profile: { firstName: 'Bob', lastName: 'Ruffward', x: 'hi' } }
var obj = { ...({firstName, lastName} = user.profile), otherData:
'otherData' }
```

So... what happened? (I'm sure you all know already)

`obj` ended up with _all_ of `user.profile`'s properties:
```
{ firstName: "Bob", lastName: "Ruffward", x: "hi", otherData: "otherData" }
```
and `firstName` and `lastName` were assigned as global variables.

```
firstName \\ "Bob"
lastName \\ "Ruffward"
```

--
Dammit babies, you've got to be kind.


On Sun, 26 May 2019 at 15:56, Григорий Карелин  wrote:

> Yep, in the same way as destructuring would work
>
> вс, 26 мая 2019 г. в 17:52, guest271314 :
>
>> If not found in source ```firstName``` and/or ```lastName``` would be
>> assigned the value ```undefined```?
>>
>> On Sun, May 26, 2019 at 1:40 PM Григорий Карелин 
>> wrote:
>>
>>> Wouldn't it be nice to have syntax like this:
>>> const obj = { {firstName, lastName from user.profile}, otherData: 'other
>>> data'  };
>>> as a syntactic sugar for
>>> const obj = {firstName: user.profile.firstName, lastName:
>>> user.profile.lastName, otherData: 'other data'};
>>>
>>> Of cause at the moment we can write it in two steps:
>>> const {fistName, lastName} = userProfile;
>>> const obj = {firstName, lastName, otherData: 'other data'}
>>>
>>> But why use extra variables?
>>>
>>> Motivating example is lodash's .pick() method:
>>> https://lodash.com/docs/#pick
>>> ___
>>> 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: Swift style syntax

[Michael Luder-Rosefield]

I've always been partial to operators merely being functions with
infix/whatever sugar; having operators without there being a corresponding
function seems deeply weird.
--
Dammit babies, you've got to be kind.


On Tue, 7 May 2019 at 05:58, Ates Goral  wrote:

> This topic has been discussed a long time ago and has stalled on
> discussions of a standard library.
>
> Coming back to the idea of adding some basic math operations directly
> on Math, there could be value in adding at least the following (from
> Isiah Meadows's post):
>
> > - `a + b` -> `Math.add` -> `:+`
> > - `a - b` -> `Math.sub` -> `:-`
> > - `a * b` -> `Math.mul` -> `:*` (different from `imul`)
> > - `a / b` -> `Math.div` -> `:/`
>
> `Math.add`: Among potentially other things, this could be useful for
> an out-of-the-box, terse way to add up items in an array. So, instead
> of:
>
> ```
> array.reduce((sum, item) => sum + item);
> ```
>
> Items could be added up with:
>
> ```
> array.reduce(Math.add);
> ```
>
> `Math.sub`: Among potentially other things, this could be useful for
> sorting numbers without having to define a custom comparator (i.e. almost
> as
> an out-of-the-box riposte to the "JavaScript WTF" refrain of
> lexicographically sorting numbers by using the default sort
> implementation.) So, instead of:
>
> ```
> array.sort((first, second) => first - second);
> ```
>
> Numbers could be sorted with:
>
> ```
> array.sort(Math.sub);
> ```
>
> `Math.mul` and `Math.div`: I don't have a compelling use case in mind,
> but I'd just throw these in for good measure / symmetry.
>
> Ates
> ___
> 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: Swift style syntax

[Michael Luder-Rosefield]

--
Dammit babies, you've got to be kind.


On Tue, 7 May 2019 at 05:58, Ates Goral  wrote:

> This topic has been discussed a long time ago and has stalled on
> discussions of a standard library.
>
> Coming back to the idea of adding some basic math operations directly
> on Math, there could be value in adding at least the following (from
> Isiah Meadows's post):
>
> > - `a + b` -> `Math.add` -> `:+`
> > - `a - b` -> `Math.sub` -> `:-`
> > - `a * b` -> `Math.mul` -> `:*` (different from `imul`)
> > - `a / b` -> `Math.div` -> `:/`
>
> `Math.add`: Among potentially other things, this could be useful for
> an out-of-the-box, terse way to add up items in an array. So, instead
> of:
>
> ```
> array.reduce((sum, item) => sum + item);
> ```
>
> Items could be added up with:
>
> ```
> array.reduce(Math.add);
> ```
>
> `Math.sub`: Among potentially other things, this could be useful for
> sorting numbers without having to define a custom comparator (i.e. almost
> as
> an out-of-the-box riposte to the "JavaScript WTF" refrain of
> lexicographically sorting numbers by using the default sort
> implementation.) So, instead of:
>
> ```
> array.sort((first, second) => first - second);
> ```
>
> Numbers could be sorted with:
>
> ```
> array.sort(Math.sub);
> ```
>
> `Math.mul` and `Math.div`: I don't have a compelling use case in mind,
> but I'd just throw these in for good measure / symmetry.
>
> Ates
> ___
> 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: Static Typing

[Michael Theriot]

On Monday, March 25, 2019, ViliusCreator 
wrote:

> ```js
>
> let a = 10
>
> a += ‘1’ // ‘101’
>
> // or
>
> a += undefined // NaN
>
> ```
>
> VS this:
>
> ```js
>
> let a: number = 10
>
> a += ‘1’ // Error, cannot convert type string to type number.
>
> // or
>
> a += undefined // Error, number doesn’t have nullable mark.
>
> ```
>
Thought experiment:

```js

let a = 10;
let b: number = 10;
a === b; // true

```

Would an error at runtime or compiletime occur here?

```js

a += '1'; // ok
b += '1'; // error

```

If it is a runtime error, is it optimal for the engine to keep track of
typed variables vs regular for the same value?

If not and it is a compiletime error, what happens here?

```js

var x = something();

a += x;
b += x; // error?

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

Re: Proposal For A New Alternative Keyword To “this” For Classes

[Michael Luder-Rosefield]

I'm getting deja vu again

On Tue, 19 Mar 2019 at 14:31 Isiah Meadows  wrote:

> UX workflows aren't all of JS. Classes exist for many more reasons than
> that, and 99% of my classes are for abstracting non-trivial business logic
> and ensuring *those* are easily testable, not directly UI/UX.
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Sun, Mar 17, 2019 at 2:35 AM kai zhu  wrote:
>
>> *rant warning*
>>
>> -1 because classes generally have little-value in UX-workflow programming.
>>
>> the example class RequestManager (given in this discussion),
>> realistically has little reusability-value -- its no better than employing
>> a throwaway static-function (both are equally likely to get rewritten each
>> time UX-workflow features are added.).
>>
>> for example, a common feature-request is adding visual-progress-bar.
>>  there is no "simple" way to extend RequestManager to do this, other than
>> significant-refactoring of the base-class (and risk breaking
>> class-dependencies downstream).
>>
>> some other common UX feature-requests that would likely invalidate
>> "reusability" of your class-based design include:
>>
>> 1. needing to upload a binary-file (social-images, receipt-signatures,
>> screenshots, etc...)
>> 2. needing to upload multiple binary-files in parallel (keeping track of
>> timeouts of each)
>> 3. needing to upload multiple binary-files in parallel (keeping track of
>> timeouts of each),
>> and then download their thumbnail-previews from server to visually
>> confirm uploads were correct
>> 4. needing to make parallel http-requests from 3rd-party sources and
>> "joining" the response-data
>> 5. needing the sign-up-page to additionally pre-validate
>> email / username / mobile-number / credit-card / etc... before
>> form-submission to server
>>
>> many frontend-engineers with experience "extending" products with
>> additional UX-workflow features, know its rarely as simple as modifying
>> some class-methods and be done with it -- it oftentimes require rewriting
>> nearly every-piece-of-code that touches the given workflow needing
>> enhancement.
>>
>> p.s. -- here's a "simple" fully-working UX-example [1] on how to add
>> visual-progress-bar to http-requests.  if i had to additionally add some of
>> the other UX-features mentioned above, it would likely entail me completely
>> rewriting the throwaway static-function, rather than waste time trying to
>> extend it.
>>
>> [1] https://jsfiddle.net/kaizhu256/t9ubdenf/
>>
>> ```html
>> 
>> /* jslint utility2:true */
>> /* csslint ignore:start */
>> *,
>> *:after,
>> *:before {
>> box-sizing: border-box;
>> }
>> /* csslint ignore:end */
>> body {
>> background: #eee;
>> font-family: Arial, Helvetica, sans-serif;
>> font-size: small;
>> }
>> input {
>> width: 100%;
>> }
>> textarea {
>> font-family: Consolas, Menlo, monospace;
>> font-size: smaller;
>> overflow: auto;
>> width: 100%;
>> }
>> 
>>
>> 
>>
>> ajax-request
>> {
>> "method": "GET",
>> "url": "https://api.github.com/orgs/octokit/repos;,
>> "headers": {
>> "accept": "application/vnd.github.v3+json"
>> },
>> "data": "hello world!"
>> }
>>
>> submit ajax-request
>>
>> ajax-response
>> 
>>
>> 
>> /*jslint browser*/
>> (function () {
>> "use strict";
>> var local;
>> local = {};
>> window.local = local;
>>
>> local.ajax = function (opt, onError) {
>> /*
>>  * simple, throwaway ajax-function that can be easily rewritten
>>  * to accomodate new [async] ux-features
>>  */
>> var resHandler;
>> var xhr;
>> opt.headers = opt.headers || {};
>> opt.method = opt.method || "GET";
>> xhr = new XMLHttpRequest();
>> // open url
>> xhr.open(opt.method, opt.url);
>> // set req-headers
>> Object.entries(opt.headers).forEach(function (entry) {
>> xhr.setRequestHeader(entry[0], entry[1]);
>> });
>> // send data
>> xhr.send(opt.data);
>> // init request-handling
>> resHandler = function (evt) {
>> /*
>>  * this function will handle ajax-response
>>  */
>> switch (evt.type) {
>> case "abort":
>> case "error":
>> // decrement ajaxProgressCounter
>> local.ajaxProgressCounter = Math.max(
>> local.ajaxProgressCounter - 1,
>> 0
>> );
>> onError(new Error(evt.type), xhr);
>> break;
>> case "load":
>> // decrement ajaxProgressCounter
>> local.ajaxProgressCounter = Math.max(
>> local.ajaxProgressCounter - 1,
>> 0
>> );
>> onError(null, xhr);
>> break;
>> }
>> // increment ajax-progress-bar
>> 

Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)

[Michael Theriot]

So this would help with precision?

On Sunday, March 10, 2019, guest271314  wrote:

> (If you really wanted this as an integer, it's not well-founded; .567
>> isn't exactly representable as a double, so JS doesn't know that you
>> "meant" it to have only three digits after the decimal point, and thus
>> want 567 as the answer. You'll instead get some very very large
>> integer that *starts with* 567, followed by a bunch of zeros, followed
>> by some randomish digits at the end.)
>
>
> The code at the first post solves that problem.
>
> But the question is still "what would someone use this information for?"
>
>
> That question has been answered several times in the posts above. This
> users' motivation was and is the ability to manipulate JavaScript
> floating-point numbers  (which could be considered "broken", as you
> described above) in order to solve mathematical problems (in this case,
> directly calculating the *n*th lexicographic permutation) with the number
> or decimal being represented as an array, without having to be concerned
> with not getting the same value when the array is converted back to a
> number.
>
> Felipe Nascimento de Moura mentioned several other applications.
>
> The work has already been done. This proposal is essentially to
> standardize the naming conventions. Whether a Number method is used
>
> i.getTensMethod
>
> or an array is used
>
>arr["integer"] // 1234
>
> or an object where values are arrays is used
>
> o["fraction"] // .567
>
> Having mentioned Intl.NumberFormat earlier in the thread, if the issue
> devoting resources to a *new *proposal, Intl.NumberFormate can be
> extended; e.g. a rough draft in code
>
> function formatNumberParts(args) {
>   return Object.assign({sign:0, fraction:[0], integer:[0]},
> ...args.filter(({type}) => type === "integer" || type === "fraction" ||
> type === "minusSign").map(({type, value}) => ({[type === "minusSign" ?
> "sign" : type]: type !== "minusSign" ? [...value].map(Number) : -1})));
> }
>
> let number = -123;
>
> let formatter = new Intl.NumberFormat('en-US');
>
> let res = formatter.formatToParts(number);
>
> formatNumberParts(res);
>
> If the concern is that the proposal would not be useful, consider what you
> would *name* various uses of Math.trunc and remainder operator used at
> your message?
>
>
> On Sun, Mar 10, 2019 at 3:58 PM Tab Atkins Jr. 
> wrote:
>
>> On Sat, Mar 9, 2019 at 11:10 AM Felipe Nascimento de Moura
>>  wrote:
>> >
>> > Personally, I don't think it would be THAT useful...
>> > but...I think there is something behind this proposal that makes sense.
>> >
>> > I do believe it could be useful for developers to have an easier access
>> to number parts or characteristics.
>> > Perhaps something like:
>> >
>> > const i = 1234.567;
>>
>> Can you provide a scenario in which these would do something useful,
>> such that it would be worth adding them over just using the math
>> operations that already exist?
>>
>> > console.log( i.float ); // 567
>>
>> i % 1
>>
>> (If you really wanted this as an integer, it's not well-founded; .567
>> isn't exactly representable as a double, so JS doesn't know that you
>> "meant" it to have only three digits after the decimal point, and thus
>> want 567 as the answer. You'll instead get some very very large
>> integer that *starts with* 567, followed by a bunch of zeros, followed
>> by some randomish digits at the end.)
>>
>> > console.log( i.abs ); // 1234
>>
>> Math.trunc(i)
>>
>> > console.log( i.thousands ); // 1
>>
>> Math.trunc(i / 1000)
>>
>> > console.log( i.million ); // 0
>>
>> Math.trunc(i / 1e6)
>>
>> > console.log( i.hundred ); // 2
>>
>> Math.trunc(i / 100) % 10
>>
>> > console.log( i.hundreds ); // 12
>>
>> Math.trunc(i / 100)
>>
>> > console.log( i.ten ); // 2
>>
>> Math.trunc(i / 10) % 10
>>
>> > console.log( i.tens ); // 123
>>
>> Math.trunc(i / 10)
>>
>> > console.log( i.tenth ); // 5
>>
>> Math.trunc(i % 1 * 10) % 10
>>
>> > console.log( i.tenths ); // 5
>>
>> Math.trunc(i % 1 * 10)
>>
>> > console.log( i.hundredth ); // 6
>>
>> Math.trunc(i % 1 * 100) % 10
>>
>> > console.log( i.hundredths ); // 56
>>
>> Math.trunc(i % 1 * 100)
>>
>>
>> Some of these are easy to remember and use; others take some thinking
>> to deploy. But the question is still "what would someone use this
>> information for?", such that the benefit to developers is worth the
>> cost to all parties involved (spec writers, implementors, testers, and
>> then developers having to navigate a larger stdlib).
>>
>> ~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: Proposal For A New Alternative Keyword To “this” For Classes

[Michael Luder-Rosefield]

How about binding `this` to a variable in the constructor? The following
syntax throws an error due to `this` being a reserved word, so won't break
any existing code:

```
class Foo {
  constructor (this: self, /* normal args */) {
// ...
  }
}
```

I can see arguments against that as it breaks the convention for how
parameter lists work, and also requires a constructor. Perhaps, then, we
could either use something like a modified version of class field
declarations to make class variables:

```
class Foo {
  const self = this;
  // ...
}
```

Or, maybe, allow parentheses before the class body to define variables:

```
class Foo (this: self) {
  //...
}
```

No, I don't like that one either.

The second suggestion (class variables as extension of class fields
proposal) seems like it has potential to me, so it seems like an excellent
time for everyone here to tell me why it's awful and stupid.

On Sun, 10 Mar 2019 at 06:59 Jordan Harband  wrote:

> The engine only has that knowledge when you call it in `a.b()` form - at
> which point, `this` is already the instance. For a keyword to not be
> context dependent, it'd have to be the instance even when you'd done
> something like `const { b } = a; b()`. To do this would require either a)
> `a` has its own distinct copy of `b` that's bound to `a`, or b) `a.b` to be
> a getter that does that binding upon request.
>
> Constructor-binding, field-binding, or arrow function fields all work the
> same way - they create a separate copy of a function for *each and every*
> instance, so that the function can point back to the instance even when
> extracted off of the object.
>
> I'm not clear on how there'd be any other way to do it.
>
> On Sat, Mar 9, 2019 at 1:41 PM john larson 
> wrote:
>
>> Although the method lives on the prototype, the engine should already
>> have knowledge of the object whose method is being invoked. I am not an
>> expert on the internal workings of the engine, so I would be glad if anyone
>> would correct me on this if I am wrong.
>>
>>
>> 
>>  Virus-free.
>> www.avast.com
>> 
>> <#m_6849901573705770350_m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband  wrote:
>>
>>> An additional keyword like this would require a function to have a
>>> hidden reference back to the instance. However, especially for `class`
>>> methods, but also for ES5-style inheritance, or even for `class Foo {}
>>> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
>>> billion instances, but only one function that uses your new keyword - how
>>> would the engine know which instance you were referring to?
>>>
>>> On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:
>>>
 Hi John,

 > I believe that it would be a trivial task for
 > current static code analyzers to restrict usage of "this" for anyone
 > opting in to use this new keyword exclusively.

 Static tooling, like the TypeScript compiler, can detect problematic
 method usage already today. Sure, having a dedicated syntax for this
 will make static analysis simpler, but I don't deem that a worthy
 addition to the language.

 > As you mentioned, arrow functions might have their own
 > problems. Wouldn't such an alternative keyword be a good addition to
 our
 > toolkit anyway?

 What I was trying to say is that your proposed alternative has exactly
 the same problems as instance-member arrow functions have today.

 Best regards,
   Bergi
 ___
 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: A way to fire logic at the end of completion of the current class method (regardless of super call order).

[Michael Haufe]

You can use a Proxy in the base class:


let handlerExample = {
get(target, prop) {
let feature = target[prop]
return feature instanceof Function ?
function () {
console.log('Before call');
let result = feature.apply(this, arguments)
console.log('After call');
return result
}
: feature
}
}

class Base {
constructor() {
return new Proxy(this, handlerExample)
 }
m1() { return "m1" }
}

class Sub extends Base {
m1() { return `override ${super.m1()}` }
m2() { return `m2` }
}

let base = new Base()
console.log(base.m1())

let sub = new Sub()
console.log(sub.m1())
console.log(sub.m2())


/Michael


On Fri, Feb 8, 2019 at 1:22 AM #!/JoePea  wrote:

 > I many times find myself in cases where a base class wants to ensure that 
 > logic is always fired after the current method's execution, so that for 
 > example no matter in which order sub classes call the `super` method, the 
 > `super` method can still guarantee that logic fires after the whole stack of 
 > the same method in the class hierarchy.

> So what I can do now is use `Promise.resolve().then(() => { ... })` to 
> schedule that logic for later, that way all the invocations of a `foo` method 
> along the class hierarchy have all fired. But this means that other code can 
> also fire before the next microtask.

> Is there some way to do it? If not, I wonder if some language feature for 
> doing it would be possible?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Native Assertions

[Michael Haufe]

Good to know that has moved forward, but it is still minimally relevant due
to the other points raised.

Also as an FYI the following paper from OOPSLA 2018:

Collapsible Contracts: Fixing a Pathology of Gradual Typing

https://www.eecs.northwestern.edu/~robby/pubs/papers/oopsla2018-fgsfs.pdf



On Sun, Jan 27, 2019 at 6:50 AM Sebastian Zartner <
sebastianzart...@gmail.com> wrote:

> console.assert is standardized by the WHATWG at
> https://console.spec.whatwg.org/#assert.
>
> Sebastian
>
> On Mon, 14 Jan 2019 at 12:39, Michael Haufe 
> wrote:
>
>> console.assert is not standardized at this point, nor is it part of the
>> language. Additionally, the semantics are inappropriate for the required
>> use cases.
>>
>> To requote the relevant part from the linked thread:
>>
>> 1. AssertionError <: Error
>> 2. assert(x === 12); // throws an AssertionError with a default error
>> message
>> 3. assert(x === 12, "twelve, supposedly") // throws an AssertionError
>> with the given error message
>>
>> console.assert does not throw and its intent is not the same. The assert
>> I'm referring to is related to Code Contracts. Therefore your reference is
>> seemingly orthogonal.
>>
>> /Michael
>>
>> On Sun, Jan 13, 2019, 12:49 Cyril Auburtin > wrote:
>>
>>> There's `console.assert`
>>>
>>> also check
>>> https://github.com/michaelficarra/proposal-first-class-protocols/issues/27#issuecomment-386975099
>>>
>>>
>>> On Sun, Dec 16, 2018 at 10:01 PM Michael Haufe 
>>> wrote:
>>>
>>>> Seven years ago there was discussion around standardizing "assert". Has
>>>> there been any movement on this since then?
>>>>
>>>> https://esdiscuss.org/topic/native-assertion-module
>>>>
>>>>
>>>> ___
>>>> 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: Chainable do sugar

[Michael Luder-Rosefield]

It's OK, you can say the m-word here. Monad. See? Nothing bad wi--

-TRANSMISSION LOST

On Fri, 18 Jan 2019 at 11:03 Paul Gray  wrote:

> Hello friends!
>
> I’d love to discuss the potential for syntax sugar around a popular fp
> pattern, *chainables*!
>
> I’ve written up a document here
>  with the
> details.
>
> I’ve also written a small Babel plugin that implements this. Here’s a
> codesandbox  with it loaded up.
>
> Thanks for your time!
>
> - Paul Gray
> ___
> 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: Native Assertions

[Michael Haufe]

If the intent of assert is only about sanity checks, then this would not be
unreasonable. C# has done similar <
https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.debug.assert?view=netframework-4.7.2
>.

If this is treated as a foot in the door for Code Contracts, then extending
debugger is inappropriate as the intentions are different.

The latter subsumes the former, but is probably a bridge too far for
ECMAScript at this stage. I would practically look for:

import {assert} from ''std:contracts"

along with comparable behavior to: <
https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts
>

/Michael

On Mon, Jan 14, 2019 at 6:53 AM Michał Wadas  wrote:

> How about extending debugger statement?
>
> Eg. debugger.assert.
>
>
>
> On Mon, 14 Jan 2019, 12:39 Michael Haufe 
>> console.assert is not standardized at this point, nor is it part of the
>> language. Additionally, the semantics are inappropriate for the required
>> use cases.
>>
>> To requote the relevant part from the linked thread:
>>
>> 1. AssertionError <: Error
>> 2. assert(x === 12); // throws an AssertionError with a default error
>> message
>> 3. assert(x === 12, "twelve, supposedly") // throws an AssertionError
>> with the given error message
>>
>> console.assert does not throw and its intent is not the same. The assert
>> I'm referring to is related to Code Contracts. Therefore your reference is
>> seemingly orthogonal.
>>
>> /Michael
>>
>> On Sun, Jan 13, 2019, 12:49 Cyril Auburtin > wrote:
>>
>>> There's `console.assert`
>>>
>>> also check
>>> https://github.com/michaelficarra/proposal-first-class-protocols/issues/27#issuecomment-386975099
>>>
>>>
>>> On Sun, Dec 16, 2018 at 10:01 PM Michael Haufe 
>>> wrote:
>>>
>>>> Seven years ago there was discussion around standardizing "assert". Has
>>>> there been any movement on this since then?
>>>>
>>>> https://esdiscuss.org/topic/native-assertion-module
>>>>
>>>>
>>>> ___
>>>> 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: Native Assertions

[Michael Haufe]

console.assert is not standardized at this point, nor is it part of the
language. Additionally, the semantics are inappropriate for the required
use cases.

To requote the relevant part from the linked thread:

1. AssertionError <: Error
2. assert(x === 12); // throws an AssertionError with a default error
message
3. assert(x === 12, "twelve, supposedly") // throws an AssertionError with
the given error message

console.assert does not throw and its intent is not the same. The assert
I'm referring to is related to Code Contracts. Therefore your reference is
seemingly orthogonal.

/Michael

On Sun, Jan 13, 2019, 12:49 Cyril Auburtin  There's `console.assert`
>
> also check
> https://github.com/michaelficarra/proposal-first-class-protocols/issues/27#issuecomment-386975099
>
>
> On Sun, Dec 16, 2018 at 10:01 PM Michael Haufe 
> wrote:
>
>> Seven years ago there was discussion around standardizing "assert". Has
>> there been any movement on this since then?
>>
>> https://esdiscuss.org/topic/native-assertion-module
>>
>>
>> ___
>> 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

Native Assertions

[Michael Haufe]

Seven years ago there was discussion around standardizing "assert". Has
there been any movement on this since then?

https://esdiscuss.org/topic/native-assertion-module
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String identity template tag

[Michael Luder-Rosefield]

Why not String.tag or .tagged?

While we're at it, is there any good reason not to have something like this:

```
String.template = (template : String, taggerFn=String.identity/tag/tagged :
Function) => (keys : Array | Object) => taggerFn(template, (keys is Array)
? ...keys : keys)
// apologies for pseudo-semi-functional code
// having keys be an object allows template to be filled by key name rather
than just index
```
This would make templates closer to the traditional usage, where the
template comes first and is later passed values to be filled in with.
Having the taggerFn as an argument allows for things like Isiah's
escape-then-apply tagging examples.


On Wed, 12 Dec 2018 at 12:51 Isiah Meadows  wrote:

> I'm not married to `identity`, and I agree the name is probably not
> ideal. I'm more concerned about functionality, though.
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
>  wrote:
> >
> > On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
> >  wrote:
> > >
> > > It'd be *way* easier to construct simple template tags if there was a
> > > built-in identity tag
> >
> > Wholeheartedly agree, a couple of months ago I considered posting
> something very similar, both for utility reasons and in hopes that it would
> be an optimization target (being a standard operation).
> >
> > I find the name `identity` unilluminating, though, partially because
> it's not quite the same meaning as the usual "identity" function (`function
> identity(x) { return x; }`), though it's close. `assemble`?
> >
> > -- 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: Proposal for faster this assignments in constructor functions

[Michael Luder-Rosefield]

``this = { ...this, par1, par2, par3 }```

Oh, wait, I'm going to point out the problem with what I wrote before
anyone else does: this will lose any non-enumerable properties on `this`,
which in a class instance is kind of a big no-no. `Object.assign` is better
here.

On Sat, 1 Dec 2018 at 20:08 Michael Luder-Rosefield 
wrote:

> > ```js
> this.{} = {par1, par2, par3};
> ```
>
> Of course, that could be expressed as ```this = { ...this, par1, par2,
> par3 }```, but that's still a bit verbose.
>
> I already know this is going to get dismissed for changing the way the `+`
> operator works, but it strikes me that a better way of expressing that
> might be ```this += { par1, par2, par3 }```.
>
> That naturally leads to having ```obj1 + obj2 === Object.assign(obj1,
> obj2)``` and ```arr1 + arr2 === (arr1 = [ ...arr1, ...arr2 ])```, which
> would be good except for the whole breaking-change thing.
>
> On Fri, 30 Nov 2018 at 22:52 Simo Costa  wrote:
>
>> Thank you T.J. Crowder for giving me your opinion on this proposal.
>> I didn't know about the Bob Myers' for pick notation and it isn't bad.
>>
>> I still prefer something like that:
>> ```js
>> constructor(this.{par1, par2, par3}) {
>> }
>> ```
>>
>> but this doesn't sound bad to me:
>>
>> ```js
>> constructor(par1, par2, par3) {
>> this.{} = {par1, par2, par3};
>> }
>> ```
>>
>> There is still a repetition, but it is a a step forward.
>>
>> Il giorno gio 29 nov 2018 alle ore 12:28 T.J. Crowder <
>> tj.crow...@farsightsoftware.com> ha scritto:
>>
>>> On Wed, Nov 28, 2018 at 6:33 PM Simo Costa
>>>  wrote:
>>> >
>>> > So my proposal is to avoid those repetitions...
>>>
>>> I'm a bit surprised to find that no one's mentioned Bob Myers'
>>> [proposal][1] for pick notation yet, which would readily address this
>>> requirement *and* various other requirements beyond initializing
>>> newly-constructed objects.
>>>
>>> Using Bob's current draft syntax, Simo's example would be:
>>>
>>> ```js
>>> constructor(par1, par2, par3) {
>>> this.{par1, par2, par3} = {par1, par2, par3};
>>> }
>>> ```
>>>
>>> or if the constructor accepts an object:
>>>
>>> ```js
>>> constructor(options) {
>>> this.{par1, par2, par3} = options;
>>> }
>>> ```
>>>
>>> But I think we can go further if we tweak the syntax a bit. Perhaps:
>>>
>>> ```js
>>> constructor(par1, par2, par3) {
>>> this.{} = {par1, par2, par3};
>>> }
>>> ```
>>>
>>> ...where the property names are inferred from the properties on the
>>> right-hand side. That would be functionally equivalent to:
>>>
>>> ```js
>>> constructor(par1, par2, par3) {
>>> Object.assign(this, {par1, par2, par3});
>>> }
>>> ```
>>>
>>> ...but since the syntax is clear about the intent, when an object
>>> initializer (rather than just object reference) is used on the right-hand
>>> side it's an optimization target if a constructor is "hot" enough to
>>> justify it (e.g., an engine could optimize it into individual assignments).
>>>
>>> For me, that would be a great, clear, concise feature, and hits the
>>> other use cases Bob mentions in his proposal. I like that I'm still in
>>> control of what parameters get assigned as properties (which I think has
>>> been true of all of the suggestsions in this thread).
>>>
>>> -- T.J. Crowder
>>>
>>> [1]: https://github.com/rtm/js-pick-notation
>>>
>> ___
>> 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 for faster this assignments in constructor functions

[Michael Luder-Rosefield]

> ```js
this.{} = {par1, par2, par3};
```

Of course, that could be expressed as ```this = { ...this, par1, par2, par3
}```, but that's still a bit verbose.

I already know this is going to get dismissed for changing the way the `+`
operator works, but it strikes me that a better way of expressing that
might be ```this += { par1, par2, par3 }```.

That naturally leads to having ```obj1 + obj2 === Object.assign(obj1,
obj2)``` and ```arr1 + arr2 === (arr1 = [ ...arr1, ...arr2 ])```, which
would be good except for the whole breaking-change thing.

On Fri, 30 Nov 2018 at 22:52 Simo Costa  wrote:

> Thank you T.J. Crowder for giving me your opinion on this proposal.
> I didn't know about the Bob Myers' for pick notation and it isn't bad.
>
> I still prefer something like that:
> ```js
> constructor(this.{par1, par2, par3}) {
> }
> ```
>
> but this doesn't sound bad to me:
>
> ```js
> constructor(par1, par2, par3) {
> this.{} = {par1, par2, par3};
> }
> ```
>
> There is still a repetition, but it is a a step forward.
>
> Il giorno gio 29 nov 2018 alle ore 12:28 T.J. Crowder <
> tj.crow...@farsightsoftware.com> ha scritto:
>
>> On Wed, Nov 28, 2018 at 6:33 PM Simo Costa
>>  wrote:
>> >
>> > So my proposal is to avoid those repetitions...
>>
>> I'm a bit surprised to find that no one's mentioned Bob Myers'
>> [proposal][1] for pick notation yet, which would readily address this
>> requirement *and* various other requirements beyond initializing
>> newly-constructed objects.
>>
>> Using Bob's current draft syntax, Simo's example would be:
>>
>> ```js
>> constructor(par1, par2, par3) {
>> this.{par1, par2, par3} = {par1, par2, par3};
>> }
>> ```
>>
>> or if the constructor accepts an object:
>>
>> ```js
>> constructor(options) {
>> this.{par1, par2, par3} = options;
>> }
>> ```
>>
>> But I think we can go further if we tweak the syntax a bit. Perhaps:
>>
>> ```js
>> constructor(par1, par2, par3) {
>> this.{} = {par1, par2, par3};
>> }
>> ```
>>
>> ...where the property names are inferred from the properties on the
>> right-hand side. That would be functionally equivalent to:
>>
>> ```js
>> constructor(par1, par2, par3) {
>> Object.assign(this, {par1, par2, par3});
>> }
>> ```
>>
>> ...but since the syntax is clear about the intent, when an object
>> initializer (rather than just object reference) is used on the right-hand
>> side it's an optimization target if a constructor is "hot" enough to
>> justify it (e.g., an engine could optimize it into individual assignments).
>>
>> For me, that would be a great, clear, concise feature, and hits the other
>> use cases Bob mentions in his proposal. I like that I'm still in control of
>> what parameters get assigned as properties (which I think has been true of
>> all of the suggestsions in this thread).
>>
>> -- T.J. Crowder
>>
>> [1]: https://github.com/rtm/js-pick-notation
>>
> ___
> 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: Numeric Array prototypes

[Michael Luder-Rosefield]

> Math.min() method doesn't work on Arrays right out of the box.

No, but rest parameters work: Math.min(...arr) is fine, and works with Sets
too.



On Wed, 21 Nov 2018 at 14:08 Isiah Meadows  wrote:

> Not sure these belong in the standard library itself. I could see max and
> min being there (these are very broadly useful), but the others, not so
> much. I'd also like both max and min accept an optional comparison callback
> of `(a, b) => a < b`. But the rest seem too narrowly useful IMHO.
> On Tue, Nov 20, 2018 at 21:38 Gbadebo Bello 
> wrote:
>
>> The array object has no method for finding the minimum value of an array
>> of numbers and the Math.min() method doesn't work on Arrays right out of
>> the box. I'll have similar issues if i wanted to return the maximum number,
>> the mean, mode,  median or standard deviations in any array of numbers.
>>
>> This is a bit tasky and can be done in just a line of code if there where
>> Array.prototype.{method}() for it.
>>
>> My proposal is, Arrays should have the following prototypes
>>
>>1. Array.prorotype.min()
>>2.  Array.prorotype.max()
>>3. Array.prorotype.mean()
>>4. Array.prorotype.median()
>>5. Array.prorotype.mode()
>>6. Array.prototype.stdev()
>>
>> The mean, median and mode would be very useful when visuali
>> Here's is a polyfill of what i'll love to propose.
>>
>> //Array.prototype.min()
>> Array.prototype.min = function(){
>> let arrayVal = this;
>> let checkNonNumbers = this.some(element => {
>> if(typeof(element) !== typeof(Math.random())){
>> throw new Error("This Array.prorotype.min() takes only array of numbers
>> as arguments");
>> }
>> else{
>> return true;
>> }
>> });
>> function findMin(validated){
>> if(validated == true){
>> return Math.min.apply( Math, arrayVal );
>> }
>> }
>> return findMin(checkNonNumbers);
>> }
>>
>> Similarly, Array.prototype.max() can be implemented as above.
>>
>>
>>
>> //Array.prototype.median()
>> Array.prototype.median = function(){
>> let values = this;
>> function median(values){
>> values.sort(function(a,b){
>> return a-b;
>> });
>> if(values.length ===0) return 0
>> var half = Math.floor(values.length / 2);
>> if (values.length % 2)
>> return values[half];
>> else
>> return (values[half - 1] + values[half]) / 2.0;
>> }
>> return median(numbers)
>> }
>> ___
>> 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: Cascade operator proposal — native fluent interfaces

[Michael Haufe]

It didn't survive the github migration AFAICT. There is no proposal listed
on the repo.

https://web.archive.org/web/20141214124428/http://wiki.ecmascript.org/doku.php?id=strawman:batch_assignment_operator

https://esdiscuss.org/topic/batch-assignment-functions

https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-05/may-23.md#moustache

On Mon, Nov 12, 2018 at 7:31 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> I have a dejavu ... a similar proposal was rejected a while ago.
>
> Can't remember its name but it was like:
>
> ```js
> foo.{
>   a.b = c;
>   d();
> }
> ```
>
> how is this different, if it's actually any different?
>
>
> On Mon, Nov 12, 2018 at 2:23 PM T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> On Sat, Nov 10, 2018 at 5:49 PM Timothy Johnson
>>  wrote:
>>
>> It's **great** to see a proposal backed by an example implementation. :-)
>>
>> I suggest adding some explanation to the proposal about how your example
>> knows the `..d()` applies to `foo` and not to `c`. From the Dart
>> documentation, I'd *guess* (not being a Dart person) that it's because
>> you'd need parens around the `c..d()` to force it to apply to that instead,
>> but... More about the specific mechanics of that as it applies to JS would
>> be useful.
>>
>> Probably also worth a one-liner that you're aware of and have allowed for
>> how this relates to numeric literals (e.g., `console.log(12..toString())`).
>> I can see in your commit on the Babel fork that you have allowed for it,
>> but for those who don't dig that deep...
>>
>> If this were in the language, I'd happily use it. I don't really feel the
>> lack of it, though.
>>
>> -- 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

export with get/set option

[Michael J. Ryan]

I mentioned something similar to this before, but wanted to update with
some more thoughts on why it could be useful...  In my specific case, I
have the following scenario...

I have a "base" script that loads build values into window.__BASE__, the
application in question is deployed on multiple clients, so strings and
other configuration values are different.  The configuration project is
built separately and the correct configuration is built with CI/CD.  There
are other configuration options that are loaded via the API that are client
configurable.  I know it's a bit different of a use case, but it can't be
*that* unique.  I also understand that it's a minefield of mutation, but
it's pretty centrally controlled early, and simplifies a *LOT* of the rest
of the application.

For example, I currently have the following in my "base.js" reference
inside my project...

// --- BEGIN JS
const base = window.__BASE__ || {}; // config from release

export const environment = base.environment || 'internal.dev';
export const api = base.api || 'https://api.app.dev-domain';
// ... other constants exported from base with defaults 

// value loaded from API before the SPA UI takes over from a spinner
export let petitionOptions = null;
export const setPetitionOptions = options => {
// client manipulation/integration here
petitionOptions = options;
};
// --- END JS

It would be nice imho if I could do the following...


// --- BEGIN JS
let _petitionOptions;
export { // no identification here, nested in object
get petitionOptions() {...},
set petitionOptions(value) {...}
};

// alternately
export get petitionOptions() {...}
export set petitionOptions(value) {...}
// --- END JS

Even more, would be the ability to do other exports via export { name:value
} in an object.  While the former method does work, I just think having a
getter/setter interface would be an interesting flexibility...  Not sure
how difficult a change it would be to making import variables assignable
and allowing the set transparently.

thoughts?

-- 
Michael J. Ryan
480-270-4509
https://www.tracker1.info/
m...@tracker1.info
track...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Has there ever been discussion around a python-like "with" syntax?

[Michael J. Ryan]

I was going to mention C#'s using statement as well... though I do like the
use of a symbol over Ron's proposal, I think using might be a better
approach.

-- 
Michael J. Ryan
480-270-4509
https://www.tracker1.info/
m...@tracker1.info
track...@gmail.com


On Mon, Oct 15, 2018 at 11:50 AM Till Schneidereit <
t...@tillschneidereit.net> wrote:

> Ron Buckton has a proposal that's quite similar to what you're talking
> about: https://github.com/tc39/proposal-using-statement
>
> On Mon, Oct 15, 2018 at 11:40 AM Dan Aprahamian 
> wrote:
>
>> Hello all! First time posting here. I was curious if there was ever talk
>> about adding something similar to python's with syntax to JS. Obviously we
>> already have a "with" keyword, but I figure we could probably use "use" as
>> the keyword instead. I was thinking something like
>>
>> // Some user defined resource that can be "entered" and "exited"
>> class MyResource {
>>   // Function called when entered
>>   async [Symbol.enter]() {
>>   }
>>
>>   // Function called when exited
>>   [Symbol.exit]() {
>>   }
>> }
>>
>> const resource = new MyResource();
>>
>> async function useResource() {
>>   use myResource {
>> // Inside here, resource has had "acquire" called on it
>>
>> await doSomethingAsync();
>> // Once this block is finished executing (including async)
>> // release is called
>>   }
>>   // Release has been called now
>> }
>>
>> Use would effectively be the equivalent of:
>>
>> async function use(resource, body) {
>>   await resource[Symbol.enter]();
>>   try {
>> await body();
>>   } finally {
>> await resource[Symbol.exit]();
>>   }
>> }
>>
>> Has something like this been considered before?
>>
>> Thanks,
>> Dan
>> ___
>> 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: await enhancement proposal: Wrap Array return values with Promise.all

[Michael Luder-Rosefield]

Would it be possible to extend `await` such that you could `await.all()`?

If not, one minor thing that might help cut down the noise (if it works
with native Promises without this-binding; I've done it with RSVP):

```
const { all } = Promise;

await all(/* */);
```

On Sun, 23 Sep 2018, 02:53 Logan Smyth,  wrote:

> Making `await` itself do this would be a breaking change, so that'd be
> very unlikely. There was discussion around an `await*` similar to the
> existing `yield*` for generators, but I think it was deemed unneeded
> complexity since `Promise.all` was already pretty easy to use, especially
> since it isn't 100% obvious from the usage of an array what should be done.
> For instance `Promise.race` also works on an iterable value. I'm not really
> involved with the process, so I can't say more though.
>
> On Sat, Sep 22, 2018 at 12:25 AM Rudi Cilibrasi 
> wrote:
>
>> Greetings,
>>
>> I have enjoyed using the `await` keyword tremendously in async code. One
>> point I notice in using it is that it is ideal in terms of clarity and
>> composability but limited in a sense to sequential composition. That is, I
>> cannot easily use `await` (by itself) to do parallel calculations.
>>
>> A few times, I have myself hit a bug where I return (without thinking) an
>> Array of Promise only to find that none will resolve using `await` on the
>> Array. I noticed others have similar bugs. [1,2] I frequently wind up
>> wrapping them in one of two ways: a) occasionally a for loop that awaits
>> each in sequence, but b) more often a `Promise.all`. I think the current
>> `await` syntax makes every kind of sequential composition quite simple to
>> read, write, and maintain, but the fact that we have to introduce
>> `Promise.all` for each case of parallel (overlapping) execution seems to be
>> a common cause of bugs and a minor aesthetic issue to me as well as perhaps
>> maintenance. It occurs to me that for my cases, and indeed perhaps others,
>> a useful rule would be that all `await` on `Array` behave as if the Array
>> were wrapped in `Promise.all`.  Then we can have a nice parallel
>> composition syntax built into the language with the keyword using Array and
>> lists can become idiomatic and concise parallel composition operators. I
>> feel like this could improve the readability, power, and real time
>> responsiveness of the language without necessarily sacrificing quality nor
>> clarity.
>>
>> await on an Array value v acts as await Promise.all(v)
>>
>> Weighing against this idea seems to be the usual: operator tricks are
>> unsearchable via keywords compared to `Promise.all`. So there is a style
>> question however with the latest addition of the great new
>> optional-chaining and pipeline ideas I thought it might be a good time to
>> give this idea a try.
>>
>> What does the group think about this await enhancement proposal?
>>
>> Best regards,
>>
>> Rudi Cilibrasi
>>
>> [1]:
>> https://stackoverflow.com/questions/38694958/javascript-async-await-for-promises-inside-array-map
>> [2]:
>> https://stackoverflow.com/questions/37360567/how-do-i-await-a-list-of-promises-in-javascript-typescript
>>
>> --
>> Happy to Code with Integrity : Software Engineering Code of Ethics and
>> Professional Practice 
>> ___
>> 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

[Michael J. Ryan]

Considering how many js devs fail to answer "what values evaluate to false
in JavaScript". It isn't the new features that are the problem.

There's a combination of problems.  People believing they're better
developers than they are.  People who look down on js and front end
development.  And those ahead to learn new things.

JS isn't really evolving any more than Java, C#, go, python and others as a
whole in the past 20 years.  And having to fight uphill to use newer
features is a pain.  I'm not on the younger side of this (I'm 42)... But
I've managed to keep up.

On Fri, Sep 21, 2018, 17:14 kai zhu  wrote:

> a problem i've observed in industry is that many es6 language-features
> have the unintended-consequence of incentivising incompetent
> javascript-developers at the expense of competent-ones.  its generally
> difficult for many employers (even those knowledgeable in general-purpose
> programming), to discern between:
>
> a) a competent javascript employee/contractor who can get things done and
> ship products (albeit with legitimate delays), and
> b) an incompetent-one who can easily hide themselves in non-productive es6
> busywork, and continually pushback product-integration (again with
> “legitimate” delays, until its too late).
>
> its gotten bad enough that many industry-employers no longer trust
> general-purpose-programming technical-interviews when recruiting js-devs,
> and rely almost exclusively on either a) an applicant's reputation /
> word-of-mouth for getting things done, or b) their ability to complete a
> time-consuming tech-challenge, where they must demonstrate ability to ship
> a mini-product.  both methods are not scalable to meet the demand in
> industry for qualified js-devs in product-development.
>
> the only solution i can think of to this industry-problem is to hold-back
> on introducing new disruptive/unproven javascript design-patterns, and
> figuring out how to educate the industry with tightened javascript
> style-guides and existing design-patterns proven to work (more is less);
> generally, ways to enhance the current, woefully inadequate “bullsh*t
> detector” of employers so they can better identify and
> mentor/train/weed-out unqualified js-devs.
>
> kai zhu
> kaizhu...@gmail.com
>
> ___
> 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

ESM exporting getters and setters.

[Michael J. Ryan]

// myFoo.mjs
_hiddenFoo = false;
export get foo() {
  return _hiddenFoo;
}

export set foo(value) {
  _hiddenFoo = !!value;
}

// main.mjs
import {foo} from './myFoo.mjs';

Not sure if this has been discussed, but would be a nice feature to have in
some cases... I know, total side effects and mutations, all the same, would
be a nice to have in a few cases.

-- 
Michael J. Ryan
480-270-4509
https://www.tracker1.info/
m...@tracker1.info
track...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Reflect.defineProperty + FromPropertyDescriptor & ToPropertyDescriptor

[Michael Dyck]

On 2018-09-04 12:02 PM, Allen Wirfs-Brock wrote:


At one point, early in the development of ES6 the draft spec. had a 
[[OriginalDescriptor]] field  (that may not be the actual name I used) in 
internal PropertyDescrptors that carried along a reference to the original 
descriptor object from which the PropertyDescriptor was derived.


It looks like you're talking about [[Origin]].

Working drafts 12 though 25 had this wording or similar:
  A Property Descriptor may be derived from an object that has properties
  that directly correspond to the fields of a Property Descriptor. Such a
  derived Property Descriptor has an additional field named [[Origin]]
  whose value is the object from which the Property Descriptor was derived.

(In case that helps anyone researching this.)

-Michael

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

Re: JSON support for BigInt in ES6.

[Michael Theriot]

I've been brainstorming a few days and this is the same idea I reached. I
just wasn't sure if returning some kind of special object (JSON.Fragment)
was a good way to handle stringify.

Elaborating, basically a third argument would come back in JSON.parse
reviver method, which is the actual string that was parsed (not the parsed
value). When stringifying, a JSON.Fragment would not get parsed but inserts
the underlying string value (which must be valid JSON).

JSON.Fragment would just be a way to use valid, raw strings in JSON. E.g.
JSON.stringify([0]) === JSON.stringify(JSON.Fragment("[0]")

On Tuesday, August 14, 2018, Michał Wadas  wrote:

> Personally, I would like to see:
> - third argument to JSON.parse reviver, "raw string"
> - new class JSON.Fragment accepting any syntactically valid JSON in
> constructor (eg. new JSON.Fragment('9')
> - returning JSON.Fragment from JSON.stringify would paste it as-it-is into
> string output
>
> This should cover any Bigint use case without breaking backward
> compatibility.
>
> On Tue, 14 Aug 2018, 07:57 Anders Rundgren, 
> wrote:
>
>> On 2018-08-14 06:55, J Decker wrote:
>> > my primary usage of json is
>> > https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_
>> API/Writing_WebSocket_client_applications#Using_JSON_to_transmit_objects
>> >
>> > in which case JSON.parse( JSON.strinigfy( msg ) ) really needs to
>> result in the same sort of thing as the input; although I guess dates do
>> get lost in translation anyway, but they could be handled as numbers with a
>> few more character exceptions ':','-'(in a number),'Z',' ' the last one
>> (the space) complicating the whole thing immensely; there is no meaning of
>> multiple numbers without a ',' between them in JSON, so maybe not so
>> impossible.
>> >
>> > and given the requirement that seems to be lost, that bigints ONLY
>> interop with bigints, they MUST decode the same as their encoding; the
>> JSONnumber type almost works; but requires custom code every time bigints
>> are used. (much like dates)
>> >
>> > what writing a JSON parser taught me, is the type of a variable is the
>> type of the data it has; and JSON does a really good job of representing
>> 99% of generally communicated types. which makes generic code quite easy...
>> without having to respecify/recast the data, the data is already the type
>> it is.
>>
>> Since the JSON standard doesn't distinguish between a single bit or
>> BigNumber, I guess you are proposing extensions to JSON?
>>
>>
>> > but there's certainly fewer of me, than of those that thing everything
>> is perfectly fine, and shouldn't evolve as the langugage has.
>> > but then there's 'don't break the net' and 'this could certainy break
>> the net'; but since bigints didn't exist before, I guess they shouldn't be
>> added now, because sending them to old code would break  the old code
>> but actually since being added; should also update JSON to support that
>> number type (although I guess base JSON doesn't suppose ES6 number
>> encodings like 0x, 0b, etc...)
>> >
>> > and again, since bigints ONLY interop with other bigints, there should
>> be no chance they will get lost in interpretation.
>> >
>> > can see JSONnumber can aid application handling; but if you send
>> bigints to an application that doesn't support bigints it's not going to
>> work anyway; so why not just let existing json.parse throw when it doens't
>> have bigint support?
>>
>> The proposal is targeting *cross-platform applications* using JSON.  The
>> only thing it adds is offering a way to use JSON Number formatting for new
>> numeric types, in addition to the quoting schemes which already are fully
>> supported (and extensively used as well).
>>
>> Example: A java class element like `BigInteger big;` used in a JSON
>> context presumes that all values targeting "big" should be treated as
>> BigIntger (=BigInt).  However, there are different practices for formatting
>> BigIntegers in JSON and they are all "right" :-)
>>
>> In essence, the proposal's only ambition is making the ES6 JSON object
>> better aligned with an already established JSON reality.
>>
>> Anders
>>
>> > On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren <
>> anders.rundgren@gmail.com >
>> wrote:
>> >
>> > For good or for worse I have written a proposal for
>> https://github.com/tc39/proposal-bigint/issues/162
>> > available at https://github.com/cyberphone/
>> es6-bigint-json-support#json-support-for-bigint-in-es6
>> >
>> > Since the proposal doesn't introduce a default serialization mode,
>> I guess nobody will be happy :-(
>> > OTOH, a fairly decent rationale for not specifying a default is
>> also provided :-)
>> > This comment is also worth reading: https://github.com/tc39/
>> proposal-bigint/issues/162#issuecomment-409700859
>> >
>> >
>> > Cheers,
>> > Anders
>> > ___
>> > es-discuss mailing list

Re: Re: Implementing an identical JSON.stringify

[Michael Theriot]

>
> Regarding cases like Reflect.construct(Number, [], String), the reason
> this throws is because the ToNumber algorithm calls ToPrimitive if its
> operand is an object. This in turn will call String.prototype.valueOf on
> the object which does not have [[StringData]]. There’s nothing funny going
> on, it’s just a weird effect in aggregate. You would just need to implement
> all the steps here — internal ops like ToNumber, ToPrimitive, etc. It’s not
> that it "considers type", but rather that these algorithms will call
> methods by specific names on objects they receive. String.prototype and
> Object.prototype both implement "valueOf", but only the former will fail
> the slot check.
>

Thanks for demystifying this. I never realized it was just ducktyping
.valueOf on the object.

```js
Number.prototype.valueOf = () => 0;

JSON.stringify(1); // 1
JSON.stringify(new Number(1)); // 0
```

I guess what confused me is that it would detect a [[NumberData]] internal
slot, but instead of unboxing to that value it tries to ducktype call
.valueOf on the object. So the presence of [[NumberData]] changes the
behavior even if it does not actually use this value.

On Sat, Aug 4, 2018 at 10:14 PM Darien Valentine 
wrote:

> Is this a question about how/if one could replicate its behavior in theory
> from ES code, or are you suggesting a change to the existing behavior for
> these exotic cases?
>
> Assuming the former:
>
> The relevant steps are [here](
> https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
> `instanceof` a value isn’t significant in this algorithm, just its slots
> (if it is an object) or its primitive type. So one can handle number and
> string by leveraging branded checks as you’ve shown — nothing more is
> needed than branded methods and typeof to manage that one.
>
> However it is ultimately not possible to replicate because there is no
> possible brand test for [[BooleanData]].
> ___
> 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: Implementing an identical JSON.stringify

[Michael Theriot]

>
> Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and
> only if `obj` has no [[NumberData]] internal slot. Ditto for String,
> Boolean and Symbol.


I already mention this and demonstrate why it is not sufficient in my
example.

Reiterated plainly:
```js
JSON.stringify(Reflect.construct(Number, [], Number)); // "0"
JSON.stringify(Reflect.construct(Number, [], String)); // TypeError
JSON.stringify(Reflect.construct(Number, [], Object)); // null
```

Even though both of these have [[NumberData]] internal slots, it also
considers the type when throwing. Hence the question if you can type check
cross-realm in a way that does not depend on internal slots.

On Sat, Aug 4, 2018 at 6:35 PM Claude Pache  wrote:

>
>
> > Le 5 août 2018 à 00:16, Michael Theriot 
> a écrit :
> >
> > `JSON.stringify` has unintuitive behavior regarding interal slots.
>
> I don’t think that anything involving an object that has a [[StringData]]
> internal slot but has `Number.prototype` in its prototype chain could have
> an ”intuitive” behaviour...
>
> >
> >
> > I think this is related to `Array.isArray`. Is there an equivalent
> `Number.isNumber`? Or is this just something only `JSON.stringify` can do?
>
> Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and
> only if `obj` has no [[NumberData]] internal slot. Ditto for String,
> Boolean and Symbol.
>
> —Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Implementing an identical JSON.stringify

[Michael Theriot]

`JSON.stringify` has unintuitive behavior regarding interal slots.

```js
// Number with[[NumberData]]
// "0"
JSON.stringify(Object(Number(0)));

// Number without [[NumberData]]
// "{}"
JSON.stringify(Reflect.construct(Object, [], Number));

// Number without [[NumberData]]
// Number with[[StringData]]
// throws TypeError
JSON.stringify(Reflect.construct(String, [], Number));

// String with[[StringData]]
// ""
JSON.stringify(Object(String()));

// String without [[StringData]]
// "{}"
JSON.stringify(Reflect.construct(Object, [], String));

// String without [[StringData]]
// String with[[NumberData]]
// throws TypeError
JSON.stringify(Reflect.construct(Number, [], String));

// Object with[[StringData]]
// "[object String]"
JSON.stringify(Reflect.construct(String, [], Object));

// Object with[[NumberData]]
// null
JSON.stringify(Reflect.construct(Number, [], Object));
```

Weird, but not impossible to implement.

* You can detect class with instanceof
* You can detect internal slots by try-catching `.prototype.valueOf`

e.g.
```js
const isNumberInstance = (item) => item instanceof Number;
const isStringInstance = (item) => item instanceof String;

const hasNumberData = (item) => {
  try { Number.prototype.valueOf.call(item); } catch { return false; }
  return true;
};
const hasStringData = (item) => {
  try { String.prototype.valueOf.call(item); } catch { return false; }
  return true;
};
```

Since this relies on having a reference to the classes, it will not work
with an instance of `Number` from another realm for example.

```js
const item = Reflect.construct(iframe.contentWindow.String, [],
iframe.contentWindow.Number);

iframe.contentWindow.Number !== Number;
```

I think this is related to `Array.isArray`. Is there an equivalent
`Number.isNumber`? Or is this just something only `JSON.stringify` can do?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: !Re: proposal: Object Members

[Michael Theriot]

I also agree private properties / instance variables should not be
class-exclusive.

I was a big fan of the syntax used in the JavaScript Classes 1.1 proposal (
https://github.com/zenparsing/js-classes-1.1#1-instance-variables) and
always felt like it could have been painlessly extended to plain old
objects.

On Fri, Aug 3, 2018 at 11:30 PM, Bob Myers  wrote:

> >  `private`, `protected`, `class`, and a few other such keywords have all
> been part of ES since long be for the TC39 board got their hands on it.
> They hadn't been implemented, but they were all a very real part of ES.
>
> Whoa. Is that just misinformed or intentionally misleading? They have
> never been "part of ES" in any meaningful sense. It was not that they had
> not been implemented; it was that they had not even been defined. To say
> they are a "real part of ES" is a strange interpretation of the meaning of
> the word "real". The notion that we would choose features to work on based
> on some designation of certain keywords as reserved long ago, and that they
> are now "languishing", is odd. Why not focus on "implementing" enum, or
> final, or throws, or any other of the dozens of reserved words?
>
> Having said that, I think it is a valid general principle that as language
> designers we should be very reluctant to use magic characters. `**` is
> fine, of course, as is `=>`, or even `@` for decorators. Personally, I
> don't think the problem of access modifiers rises to the level of
> commonality and need for conciseness that would justify eating up another
> magic  character. We also don't want JS to start looking like Perl or APL.
>
> Speaking as a self-appointed representative of Plain Old Programmers, I do
> feel a need for private fields, although it was probably starting to
> program more in TS that got me thinking that way. However, to me it feels
> odd to tie this directly to `class` syntax. Why can't I have a private
> field in a plain old object like `{a: 1}` (i.e., that would only be
> accessible via a method on that object? We already have properties which
> are enumerable and writable, for example, independent of the class
> mechanism. Why not have properties which are private in the same way?
>
> The problem,of course, is that even assuming the engines implemented the
> `private` property on descriptors, I obviously don't want to have to write
> `Object.create({}, {a: {value: 22, private: true})`. So the problem can be
> restated as trying to find some nice sugar for writing the above.  You
> know, something like `{a: 22}`. That's obviously a completely
> random syntax suggestion, just to show the idea. Perhaps we'd prefer to
> have the access modifiers be specifiable under program control as an object
> itself, to allow something like
>
> ```
> const PRIVATE = {private: true};
>
> const myObject = {a(: 2; }
> ```
>
> But what would the precise meaning of such as `private` descriptor
> property be? In operational terms, it could suffice to imagine (as a
> behavior, not as an implementation strategy) that objects would have a flag
> that would skip over private properties when doing property lookups. I
> think the right implementation is to have a private property look like it's
> not there at all when access is attempted from outside the object (in other
> words, is undefined), rather than some kind of `PrivatePropertyAccessError`.
>
> The above approach ought to be extensible to class notation:
>
> ```
> class Foo (
>   bar(): { return 22; }
> }
> ```
>
> which would end up being something like `Object.defineProperty(Foo.prototype,
> "bar", {value() {return 22; }, private: true})`.
>
> Or when classes get instance variables:
>
> ```
> class Foo {
>   bar = 22;
> ```
>
> Was anything along these lines already brought up in this discussion?
>
> Bob
>
>
> On Sat, Aug 4, 2018 at 12:30 AM Ranando King  wrote:
>
>> > It certainly doesn't look or feel like JS - it feels more like Java or
>> C#.
>>
>> `private`, `protected`, `class`, and a few other such keywords have all
>> been part of ES since long be for the TC39 board got their hands on it.
>> They hadn't been implemented, but they were all a very real part of ES. Now
>> that `class` has been implemented, it makes little sense to leave behind
>> the `private` and `protected` keywords when we are trying to implement
>> their functionality.
>>
>> > `private` looks like an identifier, and IMHO getters, setters, and
>> async functions suffer the same issue of the keyword seeming to blend in a
>> little with surrounding code.
>>
>> Have you ever thought that `var` or `let` look like identifiers? The
>> `private` and `protected` keywords serve the same role as `var` and `let`:
>> declaring a variable within a given scope or context. If you think there is
>> a good logical or rational reason to avoid using the keywords that have
>> been embedded in the language and left languishing, waiting for their
>> meaning to be implemented, then I'm willing to entertain that. If the
>> 

Re: !Re: proposal: Object Members

[Michael Theriot]

I'd argue that is 1:1 with the way subclasses work today.

Protected properties can be implemented by sharing the weakmap instance
with the parent.

Private properties can be implemented by using a unique weakmap instance
for the subclass.

I actually think it's pretty straightforward and simple.

On Friday, August 3, 2018, Ranando King  wrote:

> > 1. It's *super incredibly boilerplatey* and verbose syntactically.
>
> I'm not sure what you mean by "boilerplatey". As for being verbose, I'm
> just using the keywords everyone understands for this purpose. IMO, there's
> no advantage in trying to find some shorthand to do the same thing just
> because it saves a keystroke or two when it makes the code significantly
> more difficult to understand.
>
> > 2. `protected` on an object literal is next to useless. I've used that kind
> of feature almost never.
>
> I get where you're coming from with that. I don't see it being used very
> often (kinda like `with`), but it has to be there. If someone wants to use
> the facilities of `class` without the limitations of the keyword, and the
> intent is to build vertical hierarchies, they'll need the "protected"
> keyword on their prototype definition to share private data with descendant
> factories. It's even more necessary for people writing factory factories.
> The only other way to achieve the same thing would be to force them to use
> `Function()` or `eval` and build up the code as strings. I'd rather avoid
> that.
>
> > I also find it odd you're supporting private dynamic properties.
>
> How'd you get to the idea that I'm supporting dynamic private properties?
> The first 2 paragraphs in the implementation say that all private container
> records are sealed, and all fields in info records are added read-only. If
> it wasn't clear from that, I'm going to have to re-write that section.
> However, the intent is that after the declaration process is complete, what
> you have is all you can get. No additional private fields can be added
> later. I considered dynamic private data, but that can get very messy very
> quickly.
>
> > I actually think it's odd there is no attempt to implement dynamic
> properties in the other "private properties" proposals.
>
> It's not that odd. There are issues around inheritance when a subclass can
> remove the `protected` properties of its base. Further, exactly how do you
> add a new `protected` property at runtime? Under both proposal-class-fields
> and proposal-object-members, there is never any direct access to the
> private container record, so use of `Object.defineProperty` will never
> work. IMO, any attempt to implement dynamic private properties in any
> sensible and consistent fashion would require somehow exposing the private
> data record to the code. That's a recipe for a private data leak. Not worth
> it.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: !Re: proposal: Object Members

[Michael Theriot]

If I understand the terminology, "private dynamic properties" are easily
polyfilled via weakmaps?

I actually think it's odd there is no attempt to implement dynamic
properties in the other "private properties" proposals.

On Friday, August 3, 2018, Isiah Meadows  wrote:

> Okay, now that I look at that proposal, I see two issues right off:
>
> 1. It's *super incredibly boilerplatey* and verbose syntactically. I
> don't know very many people who'd be willing to downgrade very far
> from even what TypeScript has. (I'm specifically referring to the
> declarations here.)
> 2. `protected` on an object literal is next to useless. I've used that
> kind of feature almost never.
>
> I also find it odd you're supporting private dynamic properties. It
> does make polyfilling next to impossible, though.
>
> Just my 2 cents on it. (I glanced over this while very tired, so I
> probably missed several highlights. These are what stuck out to me.)
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Wed, Aug 1, 2018 at 11:54 PM, Ranando King  wrote:
> > https://github.com/rdking/proposal-object-members/blob/master/README.md
> >
> > On Wed, Aug 1, 2018 at 2:01 AM Isiah Meadows 
> wrote:
> >>
> >> Do you have a link to this proposal so I can take a look at it? It'd
> >> be much easier to critique it if I could see the proposal text.
> >> -
> >>
> >> Isiah Meadows
> >> cont...@isiahmeadows.com
> >> www.isiahmeadows.com
> >>
> >>
> >> On Wed, Aug 1, 2018 at 2:18 AM, Ranando King  wrote:
> >> >> If you go back a few months, what you're proposing is *very* similar,
> >> >> at
> >> >> least functionally, to my previous iteration of my proposal:
> >> >
> >> > That functional similarity is intentional. After pouring over years
> >> > worth of
> >> > posts, I figured out what the vast majority of the
> proposal-class-fields
> >> > detractors actually wanted: an elegant, easily recognized syntax for
> >> > adding
> >> > private members to objects.
> >> >
> >> >> My main problem was that trying to limit private properties to
> objects
> >> >> created within a scope got complicated in a hurry once you considered
> >> >> all
> >> >> the small details, and it just didn't seem simple anymore.
> >> >
> >> > I noticed that about your proposal too. I'm also pretty sure that
> Daniel
> >> > E.
> >> > and Kevin G. ran into the same issues back during the
> >> > proposal-private-names
> >> > days which is why the private names concept is just an implementation
> >> > detail
> >> > in their current proposal. My proposal is made less complicated by
> >> > breaking
> >> > the problem down into the 3 pieces required to make it all work:
> >> > 1. a record to store private data
> >> > 2. an array to hold references to the schema records of accessible
> >> > private
> >> > data
> >> > 3. a schema record for the sharable data.
> >> >
> >> > In this way private = encapsulated on a non-function, protected =
> >> > private +
> >> > shared, and static = encapsulated on a function. It should be easy to
> >> > sort
> >> > out how the data would be stored given such simple definitions. These
> >> > simple
> >> > definitions also mean that encapsulation is naturally confined to
> >> > definitions. Attempts to alter that state lead to strange logical
> >> > contradictions and potential leaks of encapsulated data. I have
> thought
> >> > of
> >> > the possibility that private data could be added after definition, but
> >> > every
> >> > attempt I make to consider such a thing has so far led to a risk of
> >> > leaking.
> >> >
> >> > I've been working on some code that can serve as a proof-of-concept in
> >> > ES6.
> >> > It will implement all of my proposal that can reasonably be
> implemented
> >> > in
> >> > ES6 using Proxy. It's already in the proposal repository under the POC
> >> > branch, but it's still a WIP. For now, it already supports inheriting
> >> > from
> >> > native objects. I'm working on subclassing right now. By the time I
> get
> >> > done
> >> > (likely this coming Monday), it should support every feature in my
> >> > proposal.
> >> > I'm basically using it as a means to check the viability of my
> proposal.
> >> >
> >> > On Tue, Jul 31, 2018 at 4:35 PM Isiah Meadows  >
> >> > wrote:
> >> >>
> >> >> If you go back a few months, what you're proposing is *very* similar,
> >> >> at least functionally, to my previous iteration of my proposal:
> >> >>
> >> >>
> >> >> https://github.com/isiahmeadows/private-symbol-proposal/blob/
> c5c9781d9e76123c92d8fbc83681fdd3a9b0b319/README.md
> >> >>
> >> >> My main problem was that trying to limit private properties to
> objects
> >> >> created within a scope got complicated in a hurry once you considered
> >> >> all the small details, and it just didn't seem simple anymore. It
> only
> >> >> got more complicated when you started getting into the logistics of
> >> >> integrating with modules.
> >> >>
> >> >> So I've considered the issue and explored it pretty 

Re: !Re: proposal: Object Members

[Michael Theriot]

Should a sealed/frozen object be privately extensible? I don't actually
know, but interesting point.

On Tuesday, July 31, 2018, Ranando King  wrote:

> > Consider what people often use public symbols for now.
>
> I know that I use them as fixed-value unique keys (module globals) for
> properties on objects that I export and don't want others to be aware of or
> able to touch.
>
> > For example, consider this library [1]. In this case, they use a public
> symbol for their stuff in this file [2].
>
> And as I said before, if someone passes a non-extensible object to this
> library, it breaks. Since any library can request any object be sealed or
> frozen, the implementation of this library is too fragile.
>
> > Because here, it's not a cache, but it's literally extra associated
> data in the object. And also, in that case, you *want* the engine to see
> it as a property, since it can employ relevant IC caching for it.
>
> Here's a parallel for you. Right now, Google has a database with
> information about me on it. I don't have access to that information (module
> privacy) and that information isn't stored anywhere on me or my devices
> (module locality). This is a proper conceptual model. The information
> Google is keeping about me is information they generated. Why should I have
> to pay to store their information? Thankfully I don't. However, this is
> precisely what you're claiming to be a good use case. You want module
> privacy without module locality. If I were to play at a Kevin Gibbons-like
> response, I'd say you've identified the common pattern, but that pattern
> itself is a bad use case, and the use of private symbols as you have
> defined them doesn't do anything to correct the technical issue. Since you
> cannot stick new properties onto a non-extensible object, even private
> symbols won't solve the problem with your use case.
>
> > No, I'm not. I'm drawing a distinction between a pure many-to-one 
> > association
> (weak maps) and a "has a" relationship (private symbol properties).
>
> First, for any given property bag, the keys will need to be unique, but
> that doesn't force uniqueness onto the values. As such, even properties on
> an object provided by your "private Symbol" would still be many-1. When a
> 3rd party library wants to keep information associated with an arbitrary
> object, there are only 3 choices:
> * try to store that information on the object
>   * this is what you're advocating, but it's not a good pattern. It's too
> fragile, being subject to break if the incoming object is not extensible.
> * store the information as being associated to the object (WeakMap)
>   * this is the pattern that works in all cases (but the syntax is
> cumbersome and the implementation somewhat slow)
> * return a wrapper containing the original object and the new information
> (Proxy or custom wrapper)
>   * this is another possibility, but requires that any users accept and
> use the new Proxy or wrapper object in lieu of the original.
>
> > Another scenario is for JSDOM's `Window` implementation, where they have
> a few underscore-private variables like this [3]. That particular variable
> is used in several disparate parts throughout the code base [4], but is
> still conceptually a property. This is a case where a private symbol
> property is appropriate.
>
> It's not just "conceptually" a property. It's logically a property. Why?
> Because all the objects that it exists on were constructed somewhere within
> the JSDOM library. That's me putting _my_ keys in _my_ pocket. There's
> absolutely nothing wrong with that.
>
> > Conversely in this JSDOM file [5], it's just associating data with an 
> > arbitrary
> object it happens to have, and so using the weak map makes perfect sense.
>
> Conceptually speaking, this is the same scenario as SymbolTree. In both
> cases, the library is generating information associated with an object it
> doesn't own and didn't create.
>
> > BTW, you could make a similar argument against superclass private fields
> - it's like hiding valuable info in your wallet before you receive it for
> the first time, but even after dismantling it, you can't find any
> evidence of that valuable info.
>
> That dog don't hunt. The difference here is that in your use cases,
> library A is "sneakily" storing information on object B. In the case of
> superclass private fields, subclass B has "volunteered" to take on the
> information and functionality of class A. You've essentially compared
> apples and asteroids just because they both begin with "a".
>
> On Tue, Jul 31, 2018 at 2:15 AM Isiah Meadows 
> wrote:
>
>> > Isn't this precisely what WeakMaps are for? If the data is
>> > "module-internal", then the module needs to be the owner of the data
>> store.
>> > If the data is about "arbitrary objects" (object from outside the
>> module?)
>> > then those objects are the keys to the data store. If any object is
>> thrown
>> > away, the associated data is no longer needed. If this 

Re: Streaming regexp matching

[Michael Theriot]

I'll say I have at least a few times desired a way to stream input to
RegExp. To the point I fiddled around implementing a finite state machine.

My use cases:
1. short circuiting on nth capture
2. parsing streams

On Mon, Jul 30, 2018 at 2:39 PM, Isiah Meadows 
wrote:

> There's two things I've found that need suspendable matching:
>
> 1. Partially matching against a string, which is useful with
> interactive form validation and such.
> 2. Pattern matching and replacement over a character stream, which is
> useful for things like matching against files without loading the
> entire thing into memory or easier filtering of requests.
>
> Also, it'd be nice if there was a facility to get *all* matches,
> including duplicate group matches. This is often useful for simple
> parsing, where if such support existed, you could just use a Kleene
> star instead of the standard `exec` loops (which admittedly get old).
>
> And finally, we could avoid setting regexp globals here. That would
> speed up the matcher quite a bit.
>
> So, here's my proposal:
>
> - `regexp.matcher() -> matcher` - Create a streaming regexp matcher.
> - `matcher.consume(codePoint, charSize?) -> result | undefined` -
> Consume a Unicode code point or `-1` if no more characters exist, and
> return a match result, `undefined` if no match occurred. `charSize` is
> the number of bytes represented by `codePoint` (default: 1-2 if `/u`
> is set, 1 otherwise), so it can work with other encodings flexibly.
> - `matcher.nextPossibleStart -> number` - The next possible start the
> matcher could have, for more effective buffering and stream
> management. This is implementation-defined, but it *must* be be `-1`
> after the matcher completes, and it *must* be within [0, N) otherwise,
> where N is the next returned match.
> - `result.group -> string | number | undefined` - Return the group
> index/name of the current match, or `undefined` if it's just issuing a
> match of the global regexp.
> - `result.start -> number` - Return the matched value's start index.
> - `result.end -> number` - Return the matched value's end index.
> - This does *not* modify any globals or regexp instance members. It
> only reads `regexp.lastIndex` on creation. (It doesn't operate on
> strings, so it shouldn't return any it doesn't already have.)
>
> Most RegExp methods could similarly be built using this as a base: if
> they work on strings, they can iterate their code points.
>
> As for the various concerns:
>
> - Partial matching is just iterating a string's character codes and
> seeing if the matcher ever returned non-`undefined`.
> - Streaming pattern matching is pretty obvious from just reading the API.
> - Getting all matches is just iterating the string and returning an
> object with all the groups + strings it matched.
>
> So WDYT?
>
> /cc Mathias Bynens, since I know you're involved in this kind of
> text-heavy stuff.
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> ___
> 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: proposal: Object Members

[Michael Theriot]

I'll just say it feels inconsistent with how every other property is
configured. That the key itself holds magic behavior-changing information.
It's not a use case or overhead concern.

On Monday, July 30, 2018, Isiah Meadows  wrote:

> Um, no. The use case is *extremely* limited, and that ruins a few
> optimizations you could otherwise make with private symbols (like
> caching proxy forwarding without having to bail out).
>
> Besides, whether a symbol is private requires exactly one bit to
> store, so there's no real overhead with storing it on the object.
> Heck, if you want to optimize it better, you might choose to store
> that same bit on both the symbol and the object descriptor itself, and
> I'd expect engines to do just that - it saves a pointer dereference.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Mon, Jul 30, 2018 at 1:25 AM, Michael Theriot
>  wrote:
> > Also throwing this out there, symbols would now carry additional
> > information: private or normal. Would it be better to configure this on
> > objects instead?
> >
> > E.g. `Object.setPropertySymbolVisibility(object, symbol, true / false)`
> >
> > (and then ideally sugar for this)
> >
> > That way a symbol's visibility on an object is information held on the
> > object rather than the primitive. A little more work involved, but lines
> up
> > with Object.defineProperty and symbols remain purely unique identifiers.
> >
> > On Monday, July 30, 2018, Isiah Meadows  wrote:
> >>
> >> I'm aware it's possible to misuse, but if concerns of misuse were a
> >> serious issue, we wouldn't have iterators, for example [1] [2]. But
> >> IMHO freeing weak maps from a role they weren't designed for
> >> substantially outweighs the risks of abusing them further (and the
> >> abuses are incredibly frequent).
> >>
> >> [1]:
> >> https://esdiscuss.org/topic/iterators-generators-finally-
> and-scarce-resources-was-april-10-2014-meeting-notes
> >> [2]: https://esdiscuss.org/topic/resource-management
> >>
> >> -
> >>
> >> Isiah Meadows
> >> m...@isiahmeadows.com
> >> www.isiahmeadows.com
> >>
> >>
> >> On Sun, Jul 29, 2018 at 10:55 PM, Michael Theriot
> >>  wrote:
> >> > Right, I wouldn't, but I'm concerned others would misuse it. I don't
> >> > think
> >> > it's a blocker though, and actually frees weakmaps from trying to fill
> >> > this
> >> > role.
> >> >
> >> >
> >> > On Sunday, July 29, 2018, Isiah Meadows 
> wrote:
> >> >>
> >> >> It will, but weak maps will still remain useful for cases when you're
> >> >> semantically dealing with a key/value map. In theory, you could
> >> >> implement a weak map on top of this [1], but in practice, it doesn't
> >> >> always make sense to do it. A good example of this is if you are
> >> >> "tagging" an object with data. If this data isn't really part of the
> >> >> object itself, you shouldn't be using a private symbol for it.
> Another
> >> >> good example is if you're doing simple caching and you need to clear
> >> >> the weak map by replacing it. Using private symbols for this doesn't
> >> >> really fit with the domain here, so you're more likely just to
> confuse
> >> >> future readers (including yourself) if you do this.
> >> >>
> >> >> [1]:
> >> >> https://gist.github.com/isiahmeadows/a8494868c4b193dfbf7139589f472a
> d8
> >> >> -
> >> >>
> >> >> Isiah Meadows
> >> >> m...@isiahmeadows.com
> >> >> www.isiahmeadows.com
> >> >>
> >> >>
> >> >> On Sun, Jul 29, 2018 at 10:05 PM, Michael Theriot
> >> >>  wrote:
> >> >> > Private symbols sounds like an easy win. They would be painfully
> >> >> > simple,
> >> >> > real properties, not just variables with property imitation syntax
> >> >> > that
> >> >> > undoubtedly confuses people. With the added benefit that children
> can
> >> >> > truly
> >> >> > override the base class, freedom to define private members shared
> >> >> > across
> >> >> > otherwise unrelated objects, and even injection. My only concern is
> >> >> > that
> >> >> > it
> &

Re: !Re: proposal: Object Members

[Michael Theriot]

Also throwing this out there, symbols would now carry additional
information: private or normal. Would it be better to configure this on
objects instead?

E.g. `Object.setPropertySymbolVisibility(object, symbol, true / false)`

(and then ideally sugar for this)

That way a symbol's visibility on an object is information held on the
object rather than the primitive. A little more work involved, but lines up
with Object.defineProperty and symbols remain purely unique identifiers.

On Monday, July 30, 2018, Isiah Meadows  wrote:

> I'm aware it's possible to misuse, but if concerns of misuse were a
> serious issue, we wouldn't have iterators, for example [1] [2]. But
> IMHO freeing weak maps from a role they weren't designed for
> substantially outweighs the risks of abusing them further (and the
> abuses are incredibly frequent).
>
> [1]: https://esdiscuss.org/topic/iterators-generators-finally-
> and-scarce-resources-was-april-10-2014-meeting-notes
> [2]: https://esdiscuss.org/topic/resource-management
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Sun, Jul 29, 2018 at 10:55 PM, Michael Theriot
>  wrote:
> > Right, I wouldn't, but I'm concerned others would misuse it. I don't
> think
> > it's a blocker though, and actually frees weakmaps from trying to fill
> this
> > role.
> >
> >
> > On Sunday, July 29, 2018, Isiah Meadows  wrote:
> >>
> >> It will, but weak maps will still remain useful for cases when you're
> >> semantically dealing with a key/value map. In theory, you could
> >> implement a weak map on top of this [1], but in practice, it doesn't
> >> always make sense to do it. A good example of this is if you are
> >> "tagging" an object with data. If this data isn't really part of the
> >> object itself, you shouldn't be using a private symbol for it. Another
> >> good example is if you're doing simple caching and you need to clear
> >> the weak map by replacing it. Using private symbols for this doesn't
> >> really fit with the domain here, so you're more likely just to confuse
> >> future readers (including yourself) if you do this.
> >>
> >> [1]: https://gist.github.com/isiahmeadows/
> a8494868c4b193dfbf7139589f472ad8
> >> -
> >>
> >> Isiah Meadows
> >> m...@isiahmeadows.com
> >> www.isiahmeadows.com
> >>
> >>
> >> On Sun, Jul 29, 2018 at 10:05 PM, Michael Theriot
> >>  wrote:
> >> > Private symbols sounds like an easy win. They would be painfully
> simple,
> >> > real properties, not just variables with property imitation syntax
> that
> >> > undoubtedly confuses people. With the added benefit that children can
> >> > truly
> >> > override the base class, freedom to define private members shared
> across
> >> > otherwise unrelated objects, and even injection. My only concern is
> that
> >> > it
> >> > could cross into WeakMap use cases.
> >> >
> >> >
> >> > On Sunday, July 29, 2018, Isiah Meadows 
> wrote:
> >> >>
> >> >> BTW, I came up with an alternate proposal for privacy altogether:
> >> >> https://github.com/tc39/proposal-class-fields/issues/115
> >> >>
> >> >> TL;DR: private symbols that proxies can't see and that can't be
> >> >> enumerated.
> >> >> -
> >> >>
> >> >> Isiah Meadows
> >> >> m...@isiahmeadows.com
> >> >> www.isiahmeadows.com
> >> >>
> >> >>
> >> >> On Sun, Jul 29, 2018 at 12:23 AM, Darien Valentine
> >> >>  wrote:
> >> >> >> What you're essentially asking for is a violatable private field,
> or
> >> >> >> as
> >> >> >> has been described by others, a "soft private".
> >> >> >
> >> >> > We might have different definitions here, but I would describe what
> >> >> > I’m
> >> >> > talking about as hard private. Soft private, at least as it appears
> >> >> > to
> >> >> > have
> >> >> > been defined in [prior
> >> >> >
> >> >> > discussions](https://github.com/tc39/proposal-private-
> fields/issues/33),
> >> >> > described an avenue where symbol keyed properties were given a new
> >> >> > syntactic
> >> >> > form — but they were still just regular symbol keys, and therefore

Re: !Re: proposal: Object Members

[Michael Theriot]

Right, I wouldn't, but I'm concerned others would misuse it. I don't think
it's a blocker though, and actually frees weakmaps from trying to fill this
role.

On Sunday, July 29, 2018, Isiah Meadows  wrote:

> It will, but weak maps will still remain useful for cases when you're
> semantically dealing with a key/value map. In theory, you could
> implement a weak map on top of this [1], but in practice, it doesn't
> always make sense to do it. A good example of this is if you are
> "tagging" an object with data. If this data isn't really part of the
> object itself, you shouldn't be using a private symbol for it. Another
> good example is if you're doing simple caching and you need to clear
> the weak map by replacing it. Using private symbols for this doesn't
> really fit with the domain here, so you're more likely just to confuse
> future readers (including yourself) if you do this.
>
> [1]: https://gist.github.com/isiahmeadows/a8494868c4b193dfbf7139589f472ad8
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Sun, Jul 29, 2018 at 10:05 PM, Michael Theriot
>  wrote:
> > Private symbols sounds like an easy win. They would be painfully simple,
> > real properties, not just variables with property imitation syntax that
> > undoubtedly confuses people. With the added benefit that children can
> truly
> > override the base class, freedom to define private members shared across
> > otherwise unrelated objects, and even injection. My only concern is that
> it
> > could cross into WeakMap use cases.
> >
> >
> > On Sunday, July 29, 2018, Isiah Meadows  wrote:
> >>
> >> BTW, I came up with an alternate proposal for privacy altogether:
> >> https://github.com/tc39/proposal-class-fields/issues/115
> >>
> >> TL;DR: private symbols that proxies can't see and that can't be
> >> enumerated.
> >> -
> >>
> >> Isiah Meadows
> >> m...@isiahmeadows.com
> >> www.isiahmeadows.com
> >>
> >>
> >> On Sun, Jul 29, 2018 at 12:23 AM, Darien Valentine
> >>  wrote:
> >> >> What you're essentially asking for is a violatable private field, or
> as
> >> >> has been described by others, a "soft private".
> >> >
> >> > We might have different definitions here, but I would describe what
> I’m
> >> > talking about as hard private. Soft private, at least as it appears to
> >> > have
> >> > been defined in [prior
> >> > discussions](https://github.com/tc39/proposal-private-
> fields/issues/33),
> >> > described an avenue where symbol keyed properties were given a new
> >> > syntactic
> >> > form — but they were still just regular symbol keys, and therefore
> could
> >> > be
> >> > introspected by outside agents who had not been given express
> privilege
> >> > to
> >> > do so:
> >> >
> >> >> [...] the core would be that "private state" is simply (public)
> >> >> symbol-named properties, with syntactic sugar for those symbols, and
> >> >> possibly some kind of introspection over them [...]
> >> >
> >> > The thread goes on to contrast the soft model with an earlier version
> of
> >> > the
> >> > private fields proposal seen today. The hard private example uses the
> >> > class
> >> > declaration as a pseudo-scope, but contrasting these two options as if
> >> > they
> >> > are binary is not accurate: hard private through module/function/block
> >> > scope
> >> > already exists, it is just difficult to work with in the context of
> >> > shared
> >> > prototypes — one must either use WeakMaps, technically giving
> _hardness_
> >> > because of the forgeability of `global.WeakMap` / `WeakMap.prototype`
> /
> >> > `WeakMap.prototype.get|has|set`, or be willing to either not worry
> about
> >> > garbage collection or implement it manually. This could be solved for
> >> > with a
> >> > few rather undramatic changes, though.
> >> >
> >> > Notably, the first post there lists the following as a disadvantage of
> >> > the
> >> > soft model it describes:
> >> >
> >> >> Platform objects, both within ECMAScript and in embedding
> environments,
> >> >> contain hard private state. If a library wants to be high-fidelity
> and
> >> >> just
> >> >> like a pl

Re: !Re: proposal: Object Members

[Michael Theriot]

Private symbols sounds like an easy win. They would be painfully simple,
real properties, not just variables with property imitation syntax that
undoubtedly confuses people. With the added benefit that children can truly
override the base class, freedom to define private members shared across
otherwise unrelated objects, and even injection. My only concern is that it
could cross into WeakMap use cases.

On Sunday, July 29, 2018, Isiah Meadows  wrote:

> BTW, I came up with an alternate proposal for privacy altogether:
> https://github.com/tc39/proposal-class-fields/issues/115
>
> TL;DR: private symbols that proxies can't see and that can't be enumerated.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Sun, Jul 29, 2018 at 12:23 AM, Darien Valentine
>  wrote:
> >> What you're essentially asking for is a violatable private field, or as
> >> has been described by others, a "soft private".
> >
> > We might have different definitions here, but I would describe what I’m
> > talking about as hard private. Soft private, at least as it appears to
> have
> > been defined in [prior
> > discussions](https://github.com/tc39/proposal-private-fields/issues/33),
> > described an avenue where symbol keyed properties were given a new
> syntactic
> > form — but they were still just regular symbol keys, and therefore could
> be
> > introspected by outside agents who had not been given express privilege
> to
> > do so:
> >
> >> [...] the core would be that "private state" is simply (public)
> >> symbol-named properties, with syntactic sugar for those symbols, and
> >> possibly some kind of introspection over them [...]
> >
> > The thread goes on to contrast the soft model with an earlier version of
> the
> > private fields proposal seen today. The hard private example uses the
> class
> > declaration as a pseudo-scope, but contrasting these two options as if
> they
> > are binary is not accurate: hard private through module/function/block
> scope
> > already exists, it is just difficult to work with in the context of
> shared
> > prototypes — one must either use WeakMaps, technically giving _hardness_
> > because of the forgeability of `global.WeakMap` / `WeakMap.prototype` /
> > `WeakMap.prototype.get|has|set`, or be willing to either not worry about
> > garbage collection or implement it manually. This could be solved for
> with a
> > few rather undramatic changes, though.
> >
> > Notably, the first post there lists the following as a disadvantage of
> the
> > soft model it describes:
> >
> >> Platform objects, both within ECMAScript and in embedding environments,
> >> contain hard private state. If a library wants to be high-fidelity and
> just
> >> like a platform object, soft-private state does not provide this
> (@domenic)
> >
> > ...but neither model there quite covers that use case. Platform objects
> > _can_ see each other’s private state (cf the `isView` example earlier, or
> > scan the DOM API specs / Chrome source a bit to find numerous examples).
> > It’s only the ES layer interacting with their interfaces that cannot.
> >
> > Such things can be achieved with ordinary scope, which is why the WeakMap
> > pattern has worked in practice in my experience to date, while
> > class-declaration-scoped privacy has not. It isn’t uncommon for a
> library’s
> > exposed interface to be composed of an object graph, where privacy is a
> > concern at this public interface level, but library internal state may be
> > interconnected in unexposed ways under the hood. The most familiar
> example
> > of this is a DOM node tree. As an experiment, perhaps try to implement
> the
> > relationships between HTMLFormElement, HTMLFormControlsCollection and the
> > various form control elements using either the main private fields
> proposal
> > or your alternative proposal and see what happens.
> >
> >> However, the guardian logic tries to verify that the function trying to
> >> access the private fields of an instance is a member of the same or
> >> descending prototype that was used to create that instance.
> >
> > Because I’m looking at this in terms of slots, I’d first point out that
> > prototypes don’t determine slottedness, the execution of some specific
> > constructor does. It’s during this process that slots are associated with
> > the newly minted object by its identity. But even the current private
> fields
> > proposal tracks this behavior closely, and I’m not sure how else it could
> > work. The [[Prototype]] slot of an object is typically mutable
> > (`R|O.setPrototypeOf`, `__proto__`) and forgeable (Proxy’s
> `getPrototypeOf`
> > trap). Why/how would its value matter when it comes to accessing private
> > state?
> >
> > ```js
> > const pattern = /foo/;
> > Reflect.setPrototypeOf(pattern, Date.prototype);
> > pattern instanceof Date; // true
> > pattern instanceof RegExp; // false
> > pattern.getMinutes(); // throws TypeError because [[DateValue]] slot is
> > missing
> > 

Re: JSON support for BigInt in Chrome/V8

[Michael Theriot]

I think we should move away from guessing and automagically parsing our
JSON. The fact is a JSON number != JS number. Perhaps in userland (or a
proposal...) JSON.parse could return with a JSONNumber object which the
developer decides to convert to BigInt or Number.

On Saturday, July 28, 2018, J Decker  wrote:

>
>
> On Sat, Jul 28, 2018 at 6:57 AM Michael Theriot <
> michael.lee.ther...@gmail.com> wrote:
>
>> In a language with arbitrary integer precision, Python 3 for example, the
>> way to parse a "BigInt" would just be a plain, human readable number
>> without quotes. The way to serialize it is the same. Any other kind of
>> representation is out of spec, a workaround, and belongs in userland.
>
>
> The problem with this, 'guessing' whether is't a Number() or a BigInt() is
> that numbers and bigint's don't interop.
>
> {a:123, b:123n}
> " { "a":123, "b":123 }"  any expressions that expect B to be a BigInt()
> will fail, becasue it will be in an expression of other bigints.
>
> bigInts aren't just a better Number type, but, rather require other
> bigints for their expressions.
>
>
>
>>
>> I think BigInt should serialize the same, not as strings or anything that
>> is not a number. JSON.parse being unable to parse back into BigInt is a
>> separate issue. It is solvable by using better parsing methods, not the
>> convenient built-in one which has other issues. E.g. a streaming JSON
>> parser that lets you inspect the key name and string being parsed can
>> handle this. Case solved and you can also redesign your code so you are not
>> creating a temporary object every single parse that you most likely copy
>> into actual objects later.
>>
>> Not serializing BigInt is questionable to me but even that can be solved
>> in userland.
>>
>> On Saturday, July 14, 2018, Anders Rundgren <
>> anders.rundgren@gmail.com> wrote:
>>
>>> var small = BigInt("5");
>>> var big = BigInt("553");
>>> JSON.stringify([big,small]);
>>> VM330:1 Uncaught TypeError: Do not know how to serialize a BigInt
>>> at JSON.stringify ()
>>> at :1:6
>>>
>>> JSON Number serialization has apparently reached a new level (of
>>> confusion).
>>>
>>> Personally I don't see the problem.  XML did just fine without
>>> hard-coded data types.
>>>
>>> The JSON type system is basically a relic from JavaScript.  As such it
>>> has proved to be quite useful.
>>> However, when you are outside of that scope, the point with the JSON
>>> type system gets pretty much zero since you anyway need to map extended
>>> types.
>>>
>>> Oracle's JSON-B solution which serializes small values as Number and
>>> large values as String rather than having a unified serialization based on
>>> the underlying data type seems like a pretty broken concept although indeed
>>> fully conforming to the JSON specification. "Like the Devil reads the
>>> Bible" as we say in Scandinavia :-)
>>>
>>> Adding a couple of double quotes is a major problem?  If so, it seems
>>> like a way more useful project making quotes optional for keys (named in a
>>> specific way), like they already are in JavaScript.
>>>
>>> Yeah, and of course adding support for comments.
>>>
>>> Anders
>>>
>>> ___
>>> 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: JSON support for BigInt in Chrome/V8

[Michael Theriot]

In a language with arbitrary integer precision, Python 3 for example, the
way to parse a "BigInt" would just be a plain, human readable number
without quotes. The way to serialize it is the same. Any other kind of
representation is out of spec, a workaround, and belongs in userland.

I think BigInt should serialize the same, not as strings or anything that
is not a number. JSON.parse being unable to parse back into BigInt is a
separate issue. It is solvable by using better parsing methods, not the
convenient built-in one which has other issues. E.g. a streaming JSON
parser that lets you inspect the key name and string being parsed can
handle this. Case solved and you can also redesign your code so you are not
creating a temporary object every single parse that you most likely copy
into actual objects later.

Not serializing BigInt is questionable to me but even that can be solved in
userland.

On Saturday, July 14, 2018, Anders Rundgren 
wrote:

> var small = BigInt("5");
> var big = BigInt("553");
> JSON.stringify([big,small]);
> VM330:1 Uncaught TypeError: Do not know how to serialize a BigInt
> at JSON.stringify ()
> at :1:6
>
> JSON Number serialization has apparently reached a new level (of
> confusion).
>
> Personally I don't see the problem.  XML did just fine without hard-coded
> data types.
>
> The JSON type system is basically a relic from JavaScript.  As such it has
> proved to be quite useful.
> However, when you are outside of that scope, the point with the JSON type
> system gets pretty much zero since you anyway need to map extended types.
>
> Oracle's JSON-B solution which serializes small values as Number and large
> values as String rather than having a unified serialization based on the
> underlying data type seems like a pretty broken concept although indeed
> fully conforming to the JSON specification. "Like the Devil reads the
> Bible" as we say in Scandinavia :-)
>
> Adding a couple of double quotes is a major problem?  If so, it seems like
> a way more useful project making quotes optional for keys (named in a
> specific way), like they already are in JavaScript.
>
> Yeah, and of course adding support for comments.
>
> Anders
>
> ___
> 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: Promise capability support

[Michael Theriot]

FWIW I have never heard of this terminology before either but in practice
have used the pattern myself.

On Thu, Jul 26, 2018 at 12:15 AM, Bob Myers  wrote:

> > It allows you to reveal things, selectively, just as the revealing
> module pattern does. \
>
> The revealing module pattern is so named precisely because it reveals (to
> clients) certain aspects of the "module" in question.
> Yes, it hides other aspects, but only by virtue of not revealing them.
> If you want to support the terminology of "revealing constructor pattern",
> could you please state *what* is being revealed, exactly, to *whom*?
> When I call a promise constructor I get back one thing and one thing only,
> which is a promise.
> Is the notion that it is the promise which is being revealed?
> In that sense, all APIs "reveal" their results.
> If is the intent of using this term that the content of the executor is
> being revealed to the coder when he views the code?
> All code is revealed when it is viewed.
> It would seem to me that to qualify for the name "revealing constructor
> pattern" it ought to be revealing something.
>
> >  (separately, the measure of "caught on" is not "there does not exist
> someone who has not heard of it")
>
> This group is not a court of law with evidentiary rules.
> That someone with a degree of interest in JS to the extent they are a
> regular on the ML has never heard of it would seem to mean at least that it
> has not caught on *widely*.
> I myself had worked with and read about ES6 promises extensively before I
> heard the term.
> Perhaps in the future I can write things like "It might be argued by some
> that there is some possibility that the evidence could conceivably be
> interpreted as indicating that it may be the case that it has not caught on
> widely"?
>
> In any case, "catching on", however you define it, would seem to require
> more than a grand total of two Google results for "revealing constructor
> pattern", one of which is by the person that invented it.
>
> Bob
>
> On Thu, Jul 26, 2018 at 3:13 AM Jordan Harband  wrote:
>
>> It allows you to reveal things, selectively, just as the revealing module
>> pattern does.
>>
>> (separately, the measure of "caught on" is not "there does not exist
>> someone who has not heard of it")
>>
>> On Wed, Jul 25, 2018 at 2:04 PM, Bob Myers  wrote:
>>
>>> Not to beat a dead horse but
>>>
>>> * No, it hasn't caught on, as evidenced by the recent poster who had
>>> never heard of it.
>>> * Yes, I know it's used to describe the Promise executor pattern.
>>> * "Revealing module pattern" reveals. The so-called "revealing
>>> constructor pattern" does not reveal anything. It hides. So the term is
>>> semantically incorrect from the beginning.
>>>
>>> Bob
>>>
>>> On Wed, Jul 25, 2018 at 10:55 PM Jordan Harband 
>>> wrote:
>>>
 It's already caught on - "revealing constructor pattern" is the pattern
 that describes the Promise executor.

 The "revealing module" pattern is obsolete anyways, but it functions on
 the same principle - using closures to reveal only explicit things instead
 of everything.

 On Wed, Jul 25, 2018 at 10:01 AM, Bob Myers  wrote:

> Yes, I've encountered this "revealing constructor" terminology and
> find it confusing. I hope it doesn't catch on.
> A lot of people are likely to try to associate it with the "revealing
> module" pattern, with which it actually has nothing in common.
> It's a strange term because this pattern, if one wants to characterize
> it in terms of "revealing" things,
> is more about what is **not** being revealed (to the outside world),
> not what is being revealed.
>
> It's a useful pattern seen also in the observable constructor, and
> probably deserves to have a good name,
> but I can't come up with anything myself, other than maybe the
> suboptimal "callback-based constructor".
>
> Bob
>
> On Wed, Jul 25, 2018 at 6:45 PM Isiah Meadows 
> wrote:
>
>> Here's a quick overview of the "revealing constructor" pattern, if it
>> helps: https://blog.domenic.me/the-revealing-constructor-pattern/
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>> www.isiahmeadows.com
>>
>>
>> On Wed, Jul 25, 2018 at 7:05 AM, Herbert Vojčík 
>> wrote:
>> >
>> >
>> > Isiah Meadows wrote on 20. 7. 2018 3:13:
>> >>
>> >> Sometimes, it's *very* convenient to have those `resolve`/`reject`
>> >> functions as separate functions. However, when logic gets complex
>> >> enough and you need to send them elsewhere, save a continuation,
>> etc.,
>> >> it'd be much more convenient to just have a capability object
>> exposed
>> >> more directly rather than go through the overhead and boilerplate
>> of
>> >> going through the constructor with all its callback stuff and
>> >> everything.
>> >>
>> >> It's surprisingly not as uncommon as 

Re: javascript vision thing

[Michael Theriot]

Classes are just sugar for a predominant pattern.

On Wednesday, July 25, 2018, kai zhu  wrote:

> > Classes are widely used on the web. See any modern web framework.
>
> indeed, and i conjecture in doing so, developers have caused more harm
> than good for their employers in getting their web-projects shipped, when
> JSON-serialization web-integration problems arise.
>
> On Jul 25, 2018 17:44, "Michael Theriot" 
> wrote:
> >
> > Classes are widely used on the web. See any modern web framework.
> >
> >
> > On Wednesday, July 25, 2018, kai zhu  wrote:
> >>
> >> @tj, would you or i care about nodejs/javascript if the language did
> not exist in browsers?  in fact would anyone on tc39 give a damn about
> javascript (aside from its creator) in that scenario?  as i've said before
> [ad nauseam], the only drive most of us [non-frontend-developers] have in
> javascript is making our backend-programs accessible to the masses via
> browsers/webviews.  javascript’s dominance/relevance in industry is as a
> *web-integration* language.  and its aided by its special-ability to
> directly serialize JSON data-structures (an underrated, and very useful
> web-integration feature), while most of its competitors have to rely on
> clumsy, hard-to-serialize classes.
> >>
> >> 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.  so why does tc39 insist on pushing
> distracting language-features (clumsy java-like classes,
> non-integration-friendly meta-programming, static module-loading, etc.) for
> an unrealistic future-scenario that’s not going to happen?
> >>
> >> kai zhu
> >> kaizhu...@gmail.com
> >>
> >>> On 24 Jul 2018, at 5:56 PM, T.J. Crowder  com> wrote:
> >>>
> >>> On Tue, Jul 24, 2018 at 11:27 AM, kai zhu  wrote:
> >>>>
> >>>> tldr - tc39 should focus more on JSON-friendly
> javascript-language-features
> >>>> instead of wasting-time on hard-to-serialize classes/meta-programming.
> >>>
> >>>
> >>> This is a false dichotomy (the fallacy of the either/or choice). I'd
> >>> agree we're approaching, or at, the need for the next thing after
> >>> JSON, and that some focus on that would be a good thing. That doesn't
> >>> mean stopping work on other good things. Perhaps you could take the
> >>> lead on addressing the issues you run into. I'm sure constructive
> >>> input would be welcomed.
> >>>
> >>>> my problem with tc39, is that they “claim” javascript is a
> general-purpose
> >>>> language (and try to design it as such), when industry-wise, its
> really not.
> >>>
> >>>
> >>> Yes, it is. Just because you don't see it that way doesn't mean others
> >>> don't. And others have been telling you they see it differently
> >>> repeatedly over a long period of time on this list.
> >>>
> >>>> if tc39 is sincerely
> >>>> interested in keeping javascript a dominant/relevant language in
> industry,
> >>>> they should focus on *practical* (vs *academic*) features
> >>>
> >>>
> >>> `class` notation is practical (simplifying a common pattern and making
> >>> it less error-prone). (I know you don't use that pattern. That's fine.
> >>> But lots of people do, so it's practical for them whether you like the
> >>> pattern or not.) Promises are practical (simplifying and standardizing
> >>> callbacks, making them composable; again making them less
> >>> error-prone). `async`/`await` is HUGELY practical, massively
> >>> simplifying writing asynchronous code. Arrow functions, rest and
> >>> spread, default parameter values -- all practical. (NOT trying to put
> >>> words in your mouth, but if you were going to reply "Yes, but those
> >>> problems could already be solved in others ways.", then: Sure, and we
> >>> could all write assembly code, too. But it's *useful* to address these
> >>> in the language.)
> >>>
> >>> All of them are useful beyond the web. All are also useful in web
> programming.
> >>>
> >>> I have no problem with skepticism of specific proposals. What I would
> >>> find useful, though, would be a focus on the proposal's merits, rather
> >>> than constant 

Re: javascript vision thing

[Michael Theriot]

Classes are widely used on the web. See any modern web framework.

On Wednesday, July 25, 2018, kai zhu  wrote:

> @tj, would you or i care about nodejs/javascript if the language did not
> exist in browsers?  in fact would anyone on tc39 give a damn about
> javascript (aside from its creator) in that scenario?  as i've said before
> [ad nauseam], the only drive most of us [non-frontend-developers] have in
> javascript is making our backend-programs accessible to the masses via
> browsers/webviews.  javascript’s dominance/relevance in industry is as a
> *web-integration* language.  and its aided by its special-ability to
> directly serialize JSON data-structures (an underrated, and very useful
> web-integration feature), while most of its competitors have to rely on
> clumsy, hard-to-serialize classes.
>
> 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.  so why does tc39 insist on pushing
> distracting language-features (clumsy java-like classes,
> non-integration-friendly meta-programming, static module-loading, etc.) for
> an unrealistic future-scenario that’s not going to happen?
>
> kai zhu
> kaizhu...@gmail.com
>
> On 24 Jul 2018, at 5:56 PM, T.J. Crowder 
> wrote:
>
> On Tue, Jul 24, 2018 at 11:27 AM, kai zhu  wrote:
>
> tldr - tc39 should focus more on JSON-friendly javascript-language-features
> instead of wasting-time on hard-to-serialize classes/meta-programming.
>
>
> This is a false dichotomy (the fallacy of the either/or choice). I'd
> agree we're approaching, or at, the need for the next thing after
> JSON, and that some focus on that would be a good thing. That doesn't
> mean stopping work on other good things. Perhaps you could take the
> lead on addressing the issues you run into. I'm sure constructive
> input would be welcomed.
>
> my problem with tc39, is that they “claim” javascript is a general-purpose
> language (and try to design it as such), when industry-wise, its really
> not.
>
>
> Yes, it is. Just because you don't see it that way doesn't mean others
> don't. And others have been telling you they see it differently
> repeatedly over a long period of time on this list.
>
> if tc39 is sincerely
> interested in keeping javascript a dominant/relevant language in industry,
> they should focus on *practical* (vs *academic*) features
>
>
> `class` notation is practical (simplifying a common pattern and making
> it less error-prone). (I know you don't use that pattern. That's fine.
> But lots of people do, so it's practical for them whether you like the
> pattern or not.) Promises are practical (simplifying and standardizing
> callbacks, making them composable; again making them less
> error-prone). `async`/`await` is HUGELY practical, massively
> simplifying writing asynchronous code. Arrow functions, rest and
> spread, default parameter values -- all practical. (NOT trying to put
> words in your mouth, but if you were going to reply "Yes, but those
> problems could already be solved in others ways.", then: Sure, and we
> could all write assembly code, too. But it's *useful* to address these
> in the language.)
>
> All of them are useful beyond the web. All are also useful in web
> programming.
>
> I have no problem with skepticism of specific proposals. What I would
> find useful, though, would be a focus on the proposal's merits, rather
> than constant re-raising of this claim that JavaScript is a web-only
> language. You've made that claim, ad nauseum. My view is that it's
> been rejected by the list membership and by TC39, but whether that's
> true or I'm mistaken, please stop spamming the list with it. We all
> know how you feel about it.
>
> But again: I'm sure constructive, research-based input on how to deal
> with JSON issues related to (for instance) BigInt would be welcome in
> that BigInt thread and, ideally, eventually a proposal. There's no
> need for some big conceptual argument over the course of the language
> -- that *is* a waste of time.
>
> -- T.J. Crowder
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: proposal: Object Members

[Michael Theriot]

What can classes do that ES6 can't?

On Tuesday, July 24, 2018, Andrea Giammarchi 
wrote:

> > Proxy was used to create a membrane between the public and private
> storage, and I can't prevent that proxy from being passed to external
> functions
>
> this already underlines what I mean: classes are not just syntactic sugar
> because you cannot replicate what they do, not even using ES6.
>
> having privates / proxies maybe exposed is not how I'd personally code.
>
>
>
> On Tue, Jul 24, 2018 at 5:15 PM Ranando King  wrote:
>
>> > Private fields also won't work as expected...
>>
>> Can you clarify what you're referring to? I've created a library that
>> essentially implements the functional parts of what I intend with this
>> proposal. Of course the syntax isn't the same, and Proxy was used to create
>> a membrane between the public and private storage, and I can't prevent that
>> proxy from being passed to external functions, but those are ES-specific
>> implementation details and not how it would be implemented in the engine.
>>
>> >  ... the mandatory super call in constructor is also different from
>> ES5.
>>
>> You shouldn't really try to compare ES5 and ES6. My statement that
>> "`class` is syntactic sugar" refers to the fact that anything you can do
>> with `class` in ES6 can also be done without `class` in ES6.
>>
>> > P.S. Babel mistakenly sold classes as "just sugar" and never worked
>> properly with Custom Elements and builtins extend until version 7 which is
>> still not perfect but at least it doesn't throw errors for no reason.
>>
>> Just because `class` is essentially syntactic sugar doesn't mean that the
>> desugaring is backwards compatible with older versions of the language. I
>> do not wish to imply that. Nor do I see the need to make such a statement
>> true. Such an attempt to enforce backwards compatibility to that degree
>> would prove excessively burdensome on the process of improving and adding
>> features to the language.
>>
>> On Tue, Jul 24, 2018 at 9:41 AM Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> Private fields also won't work as expected and the mandatory super call
>>> in constructor is also different from ES5. Let's add species and special
>>> class related Symbol so that it makes no sense to define classes "just
>>> sugar" + there's no point in avoiding classes at all costs when any of
>>> these features is needed.
>>>
>>> Regards
>>>
>>> P.S. Babel mistakenly sold classes as "just sugar" and never worked
>>> properly with Custom Elements and builtins extend until version 7 which is
>>> still not perfect but at least it doesn't throw errors for no reason
>>>
>>>
>>> On Tue, Jul 24, 2018 at 4:15 PM Ranando King  wrote:
>>>
>>>> @ljharb: It seems you now understand what I was trying to say. Sadly,
>>>> I'm not always the most eloquent.
>>>>
>>>> >  As you've all pointed out, it's not "just sugar" in the sense that
>>>> you couldn't do it in ES5; it's more that parallel syntax and API were
>>>> created for the new functionality in ES6.
>>>>
>>>> The intent of my proposal is to provide both member fields and
>>>> privilege levels to the `class` keyword, and the equivalent for object
>>>> literals in a way that meets with both an intuitive declaration style, and
>>>> a reasonable access notation that breaks as little as few as possible of
>>>> the developers expectations of what can and can't be done.
>>>>
>>>> On Tue, Jul 24, 2018 at 3:18 AM Jordan Harband 
>>>> wrote:
>>>>
>>>>> As you've all pointed out, it's not "just sugar" in the sense that you
>>>>> couldn't do it in ES5; it's more that parallel syntax and API were created
>>>>> for the new functionality in ES6. Thanks for providing clear code examples
>>>>> of how one might extend builtins without `class`.
>>>>>
>>>>> @kai: yes, extending builtins makes sense, in that it's an important
>>>>> part of ES6. Invoking "the web" doesn't negate *any* of the features of 
>>>>> the
>>>>> language, new or old. Separately, not every web use involves any JSON
>>>>> serialization in either direction.
>>>>>
>>>>> On Tue, Jul 24, 2018 at 12:15 AM, T.J. Crowder <
>>>>> tj.crow...@farsightso

Re: javascript vision thing

[Michael Theriot]

Native JSON streaming would be nice in my opinion.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: proposal: Object Members

[Michael Theriot]

>
> Extend builtins, in particular - ie, `super()` allows your subclass to
> obtain internal slots it can't otherwise get.
>
> Even if `class` were just sugar, I don't think I see the argument that
> that's a *good* thing to preserve.
>

`Reflect.construct` allows subclasses to obtain internal slots without
`super()` / class syntax.

```js
const SubDate = function (...args) {
  const instance = Reflect.construct(Date, args, SubDate);
  return instance;
};

Object.setPrototypeOf(SubDate.prototype, Date.prototype);

const sub = new SubDate();
sub.getDate(); // has internal slots, does not throw
sub instanceof SubDate; // true
sub instanceof Date; // true
```

This is the first I have heard `class` is anything but sugar.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promise capability support

[Michael Theriot]

So I run into this issue when waiting on multiple events I don't initiate.
What I do is create a subclass of promise that exposes these calls.

Not saying that's the ideal way to do it, but solvable in userland and
without modifying the base class.

On Thursday, July 19, 2018, Isiah Meadows  wrote:

> Sometimes, it's *very* convenient to have those `resolve`/`reject`
> functions as separate functions. However, when logic gets complex
> enough and you need to send them elsewhere, save a continuation, etc.,
> it'd be much more convenient to just have a capability object exposed
> more directly rather than go through the overhead and boilerplate of
> going through the constructor with all its callback stuff and
> everything.
>
> It's surprisingly not as uncommon as you'd expect for me to do this:
>
> ```js
> let resolve, reject
> let promise = new Promise((res, rej) => {
> resolve = res
> reject = rej
> })
> ```
>
> But doing this repeatedly gets *old*, especially when you've had to
> write it several dozen times already. And it comes up frequently when
> you're writing lower-level async utilities that require saving promise
> state and resolving it in a way that's decoupled from the promise
> itself.
>
> -
>
> So here's what I propose:
>
> - `Promise.newCapability()` - This basically returns the result of
> [this][1], just wrapped in a suitable object whose prototype is
> %PromiseCapabilityPrototype% (internal, no direct constructor). It's
> subclass-safe, so you can do it with subclasses as appropriate, too.
> - `capability.resolve(value)` - This invokes the implicit resolver
> created for it, spec'd as [[Resolve]].
> - `capability.reject(value)` - This invokes the implicit rejector
> created for it, spec'd as [[Reject]].
> - `capability.promise` - This returns the newly created promise.
>
> Yes, this is effectively a deferred API, but revealing constructors
> are a bit too rigid and wasteful for some use cases.
>
> [1]: https://tc39.github.io/ecma262/#sec-newpromisecapability
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
> ___
> 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"

[Michael Theriot]

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

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?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: const {resolve} = Promise; // fails

[Michael Luder-Rosefield]

At this point I can't ignore how much overlap there is between this and the
this-binding operator proposal
https://github.com/tc39/proposal-bind-operator

```
const resolve = ::Promise.resolve; // takes and binds
```

As someone who often extracts functions with deconstruction, I'd love for
there to be an extension to this proposal to handle this case.

```
const { resolve, reject } = ::Promise; // ?
```

That would leave the question though of what to do with nesting:

```
const { fn1, foo: { fn2 } } = ::bar; // fn1 is bound to bar. Is fn2 bound
to bar, or foo?
```

On Thu, 19 Jul 2018 at 15:58 Andrea Giammarchi 
wrote:

> I guess one example would be more explicative: why cannot public static
> methods be defined in a similar manner?
>
> ```js
> const withLazyBoundObjects = new WeakMap;
> const withLazyBoundMethods = obj => {
>   const descriptors = Object.getOwnPropertyDescriptors(obj);
>   Object.keys(descriptors).forEach(key => {
> const desc = descriptors[key];
> const {value} = desc;
> if (desc.configurable && typeof value === 'function') {
>   delete desc.value;
>   delete desc.writable;
>   desc.get = function (...args) {
> let methods = withLazyBoundObjects.get(this || obj);
> if (!methods)
>   withLazyBoundObjects.set(this, methods = Object.create(null));
> return methods[key] || (methods[key] = value.bind(this));
>   };
> }
>   });
>   return Object.defineProperties(obj, descriptors);
> };
>
> // example
> const {resolve, reject} = withLazyBoundMethods(Promise);
> resolve(123).then(console.log);
> ```
>
> On Thu, Jul 19, 2018 at 4:33 PM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> sorry, that'd be `public get resolve()` and also `public #resolve()` so
>> nobody should be confused about the fact I'm talking about public static
>> methods.
>>
>> On Thu, Jul 19, 2018 at 4:32 PM Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> I know it's about subclassing, which is why I've asked why, once there's
>>> no context, the default/base one is not considered, but since everyone came
>>> back with the subclassing issue, which is actually what I've said myself on
>>> twitter about the current state, how about changing all public static
>>> methods that need it, to be getters ?
>>>
>>> ```js
>>> class Promise {
>>>   #resolve(...args) {
>>> return this.nativeImplementation(...args);
>>>   }
>>>   get resolve() {
>>> return #resolve.bind(this);
>>>   }
>>> }
>>> ```
>>>
>>> we could argue `Promise.resolve === Promise.resolve` should be
>>> preserved, as behavior, so that we need a lazy defined getter ... **but**
>>> why not making public static restructuring from known constructors work
>>> regardless, under all circumstances ?
>>>
>>>
>>> On Thu, Jul 19, 2018 at 4:11 PM T.J. Crowder <
>>> tj.crow...@farsightsoftware.com> wrote:
>>>
 On Thu, Jul 19, 2018 at 12:56 PM, Andrea Giammarchi
  wrote:
 > Why cannot Promise methods fallback to Promise constructor when the
 > class/context is not available?

 That sounds reasonable on first glance, but I'd be concerned about what
 happens when you do it after subclassing:

 ```js
 class MyPromise extends Promise {
 // ...and adds some important feature...
 }
 // ...
 const {resolve, reject} = MyPromise;
 const p = resolve();
 p.someImportantFeature(/*...*/); // TypeError: undefined is not a
 function
 ```

 ...since `resolve` fell back to `Promise`. That feels like a footgun.
 Either subclassers would have to handle that, which they will forget to do,
 or it has to be a bit more complicated than just a simple fallback to `
 Promise` (I don't immediately know what that "more complicated" answer
 would be.)

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

[Michael Theriot]

> 'string' === typeof document.createElement('input').type
> // true

It should be noted this is a "loose check"; it does not determine whether
or not the property exists when its value equals undefined. It also
triggers getters, whereas `in` reports whether or not the property exists
without triggering a getter.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: const {resolve} = Promise; // fails

[Michael Luder-Rosefield]

I'd reinforce this with the fact that this works for RSVP.js
https://github.com/tildeio/rsvp.js/, and so the current behaviour is a
potential breaking point if code is being converted to use native Promises.

On Thu, 19 Jul 2018 at 12:56 Andrea Giammarchi 
wrote:

> As quickly discussed on Twitter, it's very inconvenient and inconsistent
> that the following fails:
>
> ```js
> const {resolve, reject} = Promise;
>
> resolve(123); // throws
> ```
>
> Compared to every other public static method in ECMAScript that works,
> including those methods that might need the contextual class, as it is for
> the Array.from case.
>
> ```js
> const {from} = Array;
>
> from({0: 'abc', length: 1}); // ["abc"] // all good
> ```
>
> Why cannot Promise methods fallback to Promise constructor when the
> class/context is not available?
>
> Wouldn't be simple/reasonable change to make so that developers
> expectations would be preserved?
>
> Best Regards.
> ___
> 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: Feature proposal

[Michael Luder-Rosefield]

This array view thing is very close to what I had in mind, and seems to
suggest to a lot of interesting possibilities.

What strikes me as the two most significant are:

   - again, 'reversed' is just one alternative iteration order through,
   though almost certainly the most useful
   - others I can think of could be 'even/odd indexes', 'random shuffle',
  'iterate-until /while-condition', and filter equivalents
   - as well as the view defining the iteration order, it could define the
   computed value
  - this would be basically a map where the value isn't computed until
  accessed; caching behaviour could be user-determined




On Thu, 19 Jul 2018 at 09:49 Isiah Meadows  wrote:

> What about this alternate proposal:
>
>
> https://github.com/isiahmeadows/array-additions-proposal/blob/master/README.md#get-arrayprototypereversed-get-typedarrayprototypereversed
>
> (I've got a myriad of other related stuff there, too.)
>
>
> On Thu, Jul 19, 2018, 04:41 Dmitry Shulgin  wrote:
>
>> Above we was talking about this.
>> consistency and handy using -- two main reasons for this proposal.
>>
>> `reverse` will also mutate my array, cause of in-place implementation.
>>
>> You can find workaround for many existing methods, but it's not handy to
>> my mind.
>>
> ___
> 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: Feature proposal

[Michael Luder-Rosefield]

Is strikes me that every single Array method that takes an iteratee
function (signature (value, index, array)) should be able to iterate
through the array in reverse, in a standardised way.

At the moment, we have:

   - every
   - filter
   - find
   - findIndex
   - forEach
   - indexOf / lastIndexOf
   - map
   - reduce / reduceRight
   - some

which is not very consistent at all. Perhaps we could add an `iterOrder`
method that changes the way the array is iterated through?

I propose it could take 1 parameter:

   - If -1 is passed in, the array is iterated through in reverse.
   - If 1,0 or undefined is passed through, the array is iterated through
   normally.
   - If an array of numbers is passed through, these represent the indexes
   in the order they will be processed.
   - Any illegible indexes in the passed-in array will be ignored
  - Any eligible indexes not given will be ignored
   - If a generator function is passed in, it should take the array (or a
   length value) and spit out indexes.
   - If a non-generator function is passed in, it should spit out an array
   of indexes, which will be used as-per arrays being passed in

Whether that iterOrder is reset after an iteration could go either way. I'd
suggest it probably should, with an option to persist.

Example:

```
let arr = [ 8,4,7,3 ];

arr.iterOrder().map(x => x) === arr
arr.iterOrder(-1).map(x => x) === arr.reverse() === [ 3,7,4,8 ]
arr.iterOrder([ 2,1 ]).map(x => x) === [ 7,4 ]
// haven't got time to give function arg examples, but randomisers would be
fairly trivial

// original indexes are preserved during iteration:
arr.iterOrder(-1).forEach((val, i) => console.log(val, i))
// > 3, 3
// > 7, 2
// > 4, 1
// > 8, 0
```

This is a messy first-pass at the problem, and I can already see potential
issues, but it would at least standardise and generalise the problem



On Wed, 18 Jul 2018 at 17:44 Cyril Auburtin 
wrote:

> sorry you get 1, and need again to subtract the array length, `arr.length
> -1 - 1` to get the final result 3
>
> Le mer. 18 juil. 2018 à 18:41, Cyril Auburtin 
> a écrit :
>
>> there you go
>> ```
>> console.log([7, 4, 6, 7, 12].findIndex((_, i, a) =>
>> isPrime(a[a.length-1-i]))); // 3
>> ```
>>
>> Le mer. 18 juil. 2018 à 11:17, Dmitry Shulgin  a
>> écrit :
>>
>>>
>>> -- Forwarded message --
>>> From: Dmitry Shulgin 
>>> Date: 2018-07-05 10:36 GMT+03:00
>>> Subject: Feature proposal
>>> To: es-discuss@mozilla.org
>>>
>>>
>>> I came across a task of finding an index of the last element in array
>>> that satisfies the condition, so i reversed array and found it by *findIndex
>>> *function.
>>> I was thinking:
>>> Why do we have *findIndex*` method, but no *findLastIndex*?
>>> It seems logical to follow *[index|lastIndex]Of* pair, doesn't it?
>>> Reversing array in this case seems too complicated to me.
>>>
>>> So, i would like to suggest new method like
>>> *Array.prototype.findLastIndex()*
>>>
>>> Example:
>>>
>>> function isPrime(element, index, array) {
>>>   var start = 2;
>>>   while (start <= Math.sqrt(element)) {
>>> if (element % start++ < 1) {
>>>   return false;
>>> }
>>>   }
>>>   return element > 1;
>>> }
>>>
>>> console.log([4, 6, 8, 12].findIndex(isPrime)); // -1, not found
>>> console.log([7, 4, 6, 7, 12].findIndexLast(isPrime)); // 3
>>>
>>>
>>> Would be glad to implement, if it makes sense.
>>>
>>> Thx for replies.
>>>
>>> P.S. Small issue on GitHub was closed due to offtop (not an issue, as i
>>> understand).
>>> https://github.com/tc39/ecma262/issues/1253
>>>
>>> ___
>>> 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: Small Proposal "!in"

[Michael Theriot]

I think it is irrelevant; the operator already exists and I would assume if
you want the negation of it you are using it correctly in the first place.
Otherwise are you not just arguing for its removal altogether? But to
answer your question one case that comes to mind is trapping get/has in a
proxy handler.

On Wednesday, July 18, 2018, Mike Samuel  wrote:

>
>
> On Wed, Jul 18, 2018 at 11:05 AM Michael Theriot <
> michael.lee.ther...@gmail.com> wrote:
>
>> I think `in` and `instanceof` could both benefit from having negated
>> versions.
>>
>> Assuming the developer is using `in` correctly, hasOwnProperty concerns
>> are irrelevant. Either way they would attempt to use !(a in b), not
>> !hasOwnProperty.
>>
>
> Why should we assume the developer is using `in` correctly?
> Apologies if I buried my question at the end.  It was, what are the use
> cases for `in` that would not be better served by an ergonomic, infix
> hasOwnProperty?
>
>
> Same reason we don't use...
>> !(a == b) // a != b
>> !(a === b) // a !== b
>>
>
>
>> !(a > b) // a <= b
>> (!(a > b) && !(a == b)) // a < b
>>
>
> I'm not sure this is relevant to your larger point, and I've already
> conceded ergonomics, but
> these last two are not equivalent because NaN is weird.
>
> a = NaN, b = 0
> [!(a > b), a <= b]  // [true, false]
> [!(a > b) && !(a == b), a < b]  // [true, false]
>
>
>
>
>
>> On Thursday, June 28, 2018, Tobias Buschor 
>> wrote:
>>
>>> I dont like to write:
>>> if ( !('x' in obj) &&  !('y' in obj) ) {
>>>  doit()
>>> }
>>>
>>> I was even tempted to write it that way:
>>> if ('x' in obj  ||  'y' in obj) { } else {
>>>  doit()
>>> }
>>>
>>> What about a !in operator to write it like this?
>>> if ('x' !in obj  &&  'y' !in obj) {
>>>  doit()
>>> }
>>>
>>> ___
>> 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

Small Proposal "!in"

[Michael Theriot]

I think `in` and `instanceof` could both benefit from having negated
versions.

Assuming the developer is using `in` correctly, hasOwnProperty concerns are
irrelevant. Either way they would attempt to use !(a in b), not
!hasOwnProperty.

Same reason we don't use...
!(a == b) // a != b
!(a === b) // a !== b
!(a > b) // a <= b
(!(a > b) && !(a == b)) // a < b

On Thursday, June 28, 2018, Tobias Buschor  wrote:

> I dont like to write:
> if ( !('x' in obj) &&  !('y' in obj) ) {
>  doit()
> }
>
> I was even tempted to write it that way:
> if ('x' in obj  ||  'y' in obj) { } else {
>  doit()
> }
>
> What about a !in operator to write it like this?
> if ('x' !in obj  &&  'y' !in obj) {
>  doit()
> }
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON support for BigInt in Chrome/V8

[Michael J. Ryan]

Out of bounds as you'd still have to parse it, but for encoding, could add
BigInt.prototype.toJSON ...

On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi 
wrote:

> I guess a better example would've been `Boolean('false')` returns true,
> but yeah, I've moved slightly forward already with everything, if you read
> other messages.
>
> Regards.
>
> On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat 
> wrote:
>
>> On 07/17/2018 04:27 AM, Andrea Giammarchi wrote:
>> > actually, never mind ... but I find it hilarious
>> that BigInt('55501') works
>> but BigInt('55501n') doesn't ^_^;;
>>
>> That's no different from how other built-in types work.  String('"foo"')
>> doesn't give you the same string as the string literal "foo".
>>
>>  Waldemar
>>
> ___
> 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] ignoreCase method

[Michael Luder-Rosefield]

Would it not be simpler to simply change the signature from
`function(value, arrayOfStrings)` to `function(...values)`?

I'd also suggest that a better, more general purpose formulation of
comparing a string against multiple values might be to use #match.
Something like:

```
const checkString = (str, { ignoreCase, startsWith, endsWith, equals }={} )
=> {
const start = startsWith || equals ? '^' : '';
const end = endsWith || equals ? '$' : '';
const rx = v => new RegExp(`${start}${v}${end}`,ignoreCase && 'i');

return { against: (...values) => values.some(value => str.match(rx(value)))
};
}
```


On Wed, 27 Jun 2018 at 11:50 Robert Wozniak 
wrote:

> Hi everyone,
>
> ignoreCase - JavaScript proposal
>
> It's a proposal to implement a new function to compare two strings but
> without case sensitivity.
>
> The proposal is bringing an important function, which is being used in
> Java. Many times in my career I had to compare two strings but ignore case
> sensitivity.
>
> I had to convert it first and then I could compare. I'd like developers to
> be able to use the function and compare two strings without worrying about
> case sensitivity.
> 1. Syntax
>
> String.prototype.ignoreCase = function(value, arrayOfStrings) {
> var secondOption = value.toLowerCase() || 
> arrayOfStrings.join(',').toLowerCase().split(',');
> var firstOption = this.valueOf().toLowerCase();
> if(typeof secondOption === 'object') {
> for(var i = 0, l = arrayOfStrings.length; i < l; i++) {
> if(firstOption === secondOption[i]) {
> return true;
> break;
> }
> }
> } else {
> if(firstOption === secondOption) {
> return true;
> } else {
> return false;
> }
> }
> };
>
> Above code presents *ignoreCase* function and what's happening inside.
>
> The function takes two parameters:
>
> (value, arrayOfStrings)
> 1.1
> "value" parameter
>
> The value parameter is the string which is going to be compared with the
> parent string chosen by the developer, for example:
>
> const stringOne = "Matheus";stringOne.ignoreCase("matheus"); // true;
>
> 1.2
> "arrayOfStrings" parameter
>
> The "arrayOfStrings" parameter is an array of strings, which are going to
> be compared with the parent string chosen by the developer. Once the parent
> string equals one of the strings in an array, it will return true and stops
> iterating through.
>
> Example:
>
> const stringOne = "Matheus";const manyStrings = ['robert', 'lucas', 
> 'matheus'];stringOne.ignoreCase('', manyStrings) // true;
>
> 2. Response
>
> The function is going to return true or false. The result depends on
> equality between chosen strings.
> 3. How does
> it work?
>
> The function converts all of the strings, which the developer chose to the
> lower case. After performing the previous operation, it compares all of
> them. If at least one, equals the provided parent string, then the function
> returns true.
>
>
> You can the proposal on my GitHub:
> https://github.com/robertjwozniak/ignoreCase
>
>
> --
> Regards,
> Robert Wozniak
> ___
> 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

Array#flat is coming to ES; would you like like some sugar with that?

[Michael Luder-Rosefield]

Apologies 'if' this is a terrible idea, but since I have just encountered a
situation where this sugar would actually be useful I'm absolutely going to
suggest it.

Extend the ... syntax to allow for flattening deconstructed arrays.
_Literally_ extend it:

array === ...(array.flat()) // i.e. depth 1
.array === ...(array.flat(0)) // unlimited depth
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Adding support for enums

[Michael J. Ryan]

Just use symbols for your action type

On Sat, Jun 9, 2018, 14:21 Doug Wade  wrote:

> Hello friends!
>
> I had a bug the other day on my team.  We use redux  to
> manage the state on our application , which
> is maintained by a large team.  In Redux, there are actions, which are
> strings, that get passed to a reducer, which mutates the states.  My
> coworker and I inadvertently added the same action name, "LOADING" on the
> same page, but in two different files.  This led to a bug when both my
> modal and his search results would be loading at the same time, but since
> they were never both visible, we didn't catch the bug.  My coworker
> refactored his feature, and broke my feature, such that rather than
> displaying a spinner, we went straight to an empty results page, even when
> there were results.
>
> In other languages, like the language I use most at work, Java, we would
> instead use a language construct called an enum
>  in this situation so that
> the two different sets of actions weren't equal to each other.  I did some
> research into some previous discussions on this
>  topic, and it seems like the
> discussion has been broadly in favor of it. I also noted that enum is a 
> reserved
> keyword
> ,
> which indicates some intention to add enums to the language.
>
> As such, I've spent some time working on a proposal
>  for adding enums
> to ECMAScript. It is very heavily based on the work by rauschma
> , stevekinney
>  and rwaldron
> . I wasn't sure if
> I was using all the right words when writing the proposal, so to help
> express myself better, I also spent some time writing a babel plugin
>  that
> uses a polyfill  against
> which I've written a small test suite
>  (if you would like to run
> them, you'll need to link the polyfill and the babel plugin into the
> tests). Please do not take these as any indication of "done-ness", I wrote
> them to understand how I would expect an enum in javascript to behave, and
> am willing and eager to make changes as I get suggestions. I do, however,
> feel I have done as much as I can on my own, and would like help in
> considering the proposal, especially whether it contains any footguns,
> undefined behavior, or things that would be surprising to newer developers,
> and helping me identify what work is to be done to make this a "real"
> proposal.
>
> All the best,
> Doug Wade
>
> ___
> 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: Symbol history

[Michael Dyck]

On 2018-05-28 02:09 PM, T.J. Crowder wrote:


Am I right that Symbols started out as "private Name objects" then over time 
their name was changed, they became primitives,


As far as the spec is concerned...

Symbols were introduced in draft 12 of ES6.
They were defined as a kind of exotic object, stateless and immutable.

In draft 15, Symbol became a primitive type.
In draft 16, it went back to being a kind of exotic object.
In draft 19, it went back to being a primitive type.

You can find the drafts here:
http://web.archive.org/web/20131017074027/http://wiki.ecmascript.org:80/doku.php?id=harmony:specification_drafts

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

Re: Proposal: Phase-Invariant Einno Soliton Templates

[Michael Luder-Rosefield]

I've been suspecting along similar lines, but was reticent to make any
outright accusations.

On Mon, 21 May 2018, 00:41 Sanford Whiteman, <
swhitemanlistens-softw...@figureone.com> wrote:

> > I personally would prefer that these proposals are specified in terms
> > of *what's actually being proposed*
>
> I think what's actually being proposed is that we fall for a troll.
>
> Possibly an academic troll who will later ridicule its victims, viz.
> the Social Text scandal (https://en.wikipedia.org/wiki/Sokal_affair).
>
> A pity, since I love receiving this list to graze over your and
> others' intelligent and serious comments on the future of the
> language.
>
> —— Sandy
>
> ___
> 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: Phase-Invariant Einno Soliton Templates

[Michael Luder-Rosefield]

At this point I fully expect Abdul to describe the Norse, Greek and Hindu
pantheons in terms of turbulence physics and give a few pseudocode JS
snippets indicating that they can also be used to handle REST requests.
And all in 3 short sentences.

On Sun, 20 May 2018 at 02:49 kdex  wrote:

> To me, what you're actually seeking to discuss looks less related to
> physics
> and more like an extension to ECMAScript's `import` syntax.
>
> Would you please describe it a little more? A good conversation starter,
> preferably without any domain-specific context (i.e. physics), would
> entail:
>
> - the set of generalized (= non-domain-specific) problems it solves
> - the desugaring you have in mind
> - how a solution to your problem might look without introducing new syntax
> (ideally also the reasoning why you consider new syntax to be justified)
>
> On Sunday, May 20, 2018 3:12:34 AM CEST Abdul Shabazz wrote:
> > Of the five (5) known forms of matter:
> >
> >
> >
> >1. Solid (well-structured arrangement of tightly bound atoms, found in
> >ice)
> >2. Liquid (unstructured arrangement of tightly-bound atoms)
> >3. Gas (loose arrangement of atoms)
> >4. Plasma (Properties of liquid, electricity, and magnetism found @
> the
> >core of our sun)
> >5. Bose-Einstein condensates (Properties of gas and phase-invariant
> >liquid, ie. a superfluid)
> >
> >
> > ...Another sixth (6th) form of matter was uncovered six weeks ago at UT
> > Dallas: the "Superfluid Quasicrystal" -- which has the properties of both
> > quasicrystals and superfluids, wherein Quasi crystals have atoms that are
> > arranged in a highly ordered, periodic pattern that is unchanged when you
> > rotate or repeat it, eg. in table salts)
> >
> >
> > This sixth (6th) form of matter exhibits properties of a Soliton: A
> Soliton
> > or Einno Soliton Tsunami is a gathering phase-invariant wave that
> maintains
> > its shape and velocity as it travels through any phase of matter.
> >
> >
> > An example implementation perhaps in javascript would be:
> >
> >
> > // file1.jsol
> >
> >
> > ${0} = (lhs,rhs) => { return (lhs ${1} rhs) }
> >
> >
> > // file2.js
> >
> >
> > import file1.["add",Symbol.operator.addition] as bar
> >
> > let foo = bar.add(4,2) // returns 6
> >
> >
> > // file3.js
> >
> >
> > import file1.["mul",Symbol.operator.multiplication] as bar
> >
> > let foo = bar.mul(4,2) // returns
> 8___
> 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: Proposal: Pilot-Wave -based execution flow

[Michael Luder-Rosefield]

can I be the first to say: what


On Sat, 12 May 2018, 16:31 Abdul Shabazz,  wrote:

> A velocity vector can also be added to detect the presence of malware,
> which in turn can effect the mass. If the mass at any point is changed,
> then the pipeline is dropped.
> --
> Abdul S.
> ___
> 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: Implicit variables

[Michael Luder-Rosefield]

Could you suggest an example?

On Wed, 9 May 2018 at 14:50 Abdul Shabazz  wrote:

> Allow javascript to facilitate implicit variables by way of an advanced
> built-in reasoning engine or theorem prover. Thereby, allowing javascript
> to become a more powerful semantics driven language whereby the software
> developer need not always be bothered with implementation.
> --
> Abdul S.
> ___
> 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