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 e

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

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

Re: Suggestion: Infix operators/functions

[Michael Haufe]

How would operator precedence work? Would we be restricted to 2-argument
functions only?



On Fri, Feb 2, 2018 at 5:55 AM, Thomas Grainger  wrote:

> I'm porting this from the TypeScript issue tracker, original from:
> https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
>
> Since it's very unlikely that the extension methods will ever be
> implemented [in a call-site-rewrite
> manner](https://github.com/Microsoft/TypeScript/issues/9#iss
> uecomment-74302592),
> please consider adding infix operators to enable writing in functional
> style similarly to what can be done in Haskell:
>
> Monoids
>
> ```js
>
> function '+' (left, right) {
>return left.concat(right);
> }
>
> [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
>
> ```
>
> Monads
>
> ```js
> function '>>=' (promise, bind) {
>return promise.then(bind);
> }
> $.get('/get') '>>=' x => $.post('/save', x + 1)
> ```
>
> Functors
>
> ```js
> function '.' (inner, outer) {
>return function(value: a) : c {
>   return outer(inner(value))
>}
> }
>
> function f(x) { }
> function g(y) { }
> (f '.' g)(x); // z
> ```
>
>
>
> Thomas Grainger
>
> ___
> 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: ASI edits

[Michael Haufe]

Matt Might's MC Lexer is one example of a currying based DSL:

<
http://matt.might.net/articles/lexing-and-syntax-highlighting-in-javascript/
>

For example, to emulate what Lex provides:

// *state* (*regex*) (*action*) ;

   [_A-Za-z]+{ return(ID) ; }
   [0-9]+{ return(NUM) ; }

in JavaScript you'd do:

INIT(/[_A-Za-z]+/)(function () { return ID ; }) ;
INIT(/[0-9]+/)(function () { return NUM ; }) ;


or more modernly:

INIT(/[_A-Za-z]+/)(() => ID );
INIT(/[0-9]+/)(() => NUM ) ;



On Sat, Jan 13, 2018 at 8:31 PM, Isiah Meadows 
wrote:

>
> On Sat, Jan 13, 2018 at 9:54 AM, Claude Pache 
> wrote:
> >
> > [...]
> >
> > I think that the BC incompatibility issue is more than just a risk. I
> recall
> > (but I couldn’t find it) that someone gave the example of some library
> that
> > reads better when used as:
> >
> > ```js
> > foo
> >   (bar)
> >   (baz)
> > ```
>
> Do you have any ideas where I could look to potentially find it? I've
> never seen *that* kind of DSL before, and that's an interesting use
> case I haven't considered.
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Identifying pure (or "pure within a scope") JavaScript functions?

[Michael Haufe]

Relevant discussions:

<
https://groups.google.com/d/msg/mozilla.dev.tech.js-engine/aSKg4LujHuM/2Y9ORBwCIQAJ
>

and:

<
https://mail.mozilla.org/pipermail/es-discuss/2012-November/thread.html#26657
>


On Thu, Dec 7, 2017 at 11:15 AM, Michał Wadas  wrote:

> Only extremely small subset of functions can be proven to be pure. And I
> suppose that these functions are already optimized by engines.
>
> eg.
> notPure = (a,b) => a + b; // implicit conversion with side effects can
> happen
> notPure = (a) => a && a.b; // getter can be called
> notPure = (foo, bar) => Reflect.has(foo, bar); // proxy trap can be
> called. Someone could overwrite Reflect.has
>
> etc.
>
> It would be better idea to have builtin decorator *@pure* that allow
> engine to remove or reorganize function calls (and valid implementation can
> treat it as no-op).
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Block scoped prototype extensions

[Michael Haufe]

Tagged Template literals exist:

<
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#Tagged_template_literals
>

On Wed, Jul 5, 2017 at 2:03 PM, kdex  wrote:

> … which I would be very happy to discuss, nonetheless.
> It's indeed a little painful to work with derived built-ins if you can't
> use
> literals.
>
> Could we maybe have a syntax that, for its current block, declares how to
> interpret literals? Maybe something along the lines of:
>
> ```js
> class MyArray extends Array {};
> Array as MyArray;
> const array = [1, 2, 3];
> assert(array instanceof MyArray);
> ```
>
> On Wednesday, July 5, 2017 8:47:53 PM CEST kdex wrote:
> > Overriding literals with a derived class is an entirely different
> problem.
> > :)
> > On Wednesday, July 5, 2017 8:42:39 PM CEST Boris Cherny wrote:
> > > I tried that approach, but it doesn’t work when creating objects via
> > > literal notation ([], {}). A bit clumsy to have to write “new
> > > Array(1,2,3)", or “Array(1,2,3)” every time.
> > > ___ 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

Determining if an object can be constructed

[Michael Haufe]

The question came up recently on CLJS [1] on how to determine if an object
is safe to call as a Constructor.

Traditionally one uses try {... x = new foo() ... } catch(e) { ... x =
foo() }


In the list of well-known symbols [2] there doesn't seem to be a way to
reference [[Construct]] to perform a test to avoid the try/catch.  In the
following[3] though there is reference to Symbol.create which doesn't seem
to be in the spec but seems to be the one to look for. Can we get
clarification on if it is possible to determine if an object can be
constructed before attempting it?

[1] <
https://groups.google.com/forum/#!msg/comp.lang.javascript/nSesJfznwjg/rKiQOzkYEwAJ
>
[2] 
[3] <
https://github.com/lukehoban/es6features/blob/master/README.md#subclassable-built-ins
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Can't do push in forEach

[Michael Haufe]

...but you can do this:

[].push.apply(arr1,arr2);

On Thu, May 14, 2015 at 9:25 AM, Emanuel Allen 
wrote:

> Surprise that I can't do arr1.forEeach(arr2.push);
>
> Will throw an error.
>
> Using bind as:
>
> push = arr2.bind(push);
> arr1.forEeach(push);
>
> Works... And not work. Seem to push individual elements and after every
> second element, it'll push the hold array.. And after and before each index
> that hold the array there are duplicate of that element preceding and
> following:
>
> [1,2,array,2,3]//not this is with shift method
> [1,2,array,3,2]//note that this is with push
>
>
> JS4L
> ___
> 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: let function

[Michael Haufe]

As Perlis has said: too much syntactic sugar causes cancer of the
semicolon. IMO, this is not much of a win given what is now available,
especially with arrow functions and shorthand method definitions


On Thu, May 14, 2015 at 1:37 PM, Alexander Jones  wrote:

> Propose adding support for
>
> let function foo() {};
>
> which would have the equivalence of:
>
> let foo = function foo() {};
>
> The idea is to support the normal scoping of let, but without forcing you
> to repeat yourself when naming the function, whilst still having the
> function's name property be set.
>
> This would trivially extend to const and var. Also, possibly class.
>
> Thanks
>
>
> ___
> 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: Array.prototype.contains

[Michael Haufe]

Array.prototype.removeAt(index);
Array.prototype.remove(element);



On Wed, Jul 23, 2014 at 3:12 PM, Alex Vincent  wrote:

> On Wed, Jul 23, 2014 at 11:18 AM,  wrote:
>
>> So too, for cases of removing an item, would Array.prototype.remove(v)
>> show clear intent.
>>
>
> I would actually raise a concern about that method.  Suppose v shows up in
> the array more than once.  Do you remove the first appearance, the last, or
> all of them?
>
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
>
> ___
> 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: Efficient 64 bit arithmetic

[Michael Haufe]

Latest news on "div" AFAIK:

https://mail.mozilla.org/pipermail/es-discuss/2013-July/thread.html#32221


On Tue, Jul 8, 2014 at 10:45 AM, Filip Pizlo  wrote:

> I like this a lot.
>
> It looks like it will have a fairly mellow performance cliff in cases
> where VM optimizations fail for whatever reason, since even in a lower-tier
> compiler incapable of sophisticated optimizations all you really have to do
> is make sure that these new math function calls bottom out in something
> efficient.
>
> This would be even better if there was a story for div and mod. Is there
> one?
>
> -Filip
>
> > On Jul 8, 2014, at 7:59 AM, Fabrice Bellard  wrote:
> >
> > Hi all,
> >
> > Regarding 64 bit arithmetic, there is a simpler solution compared to
> what was proposed in [1]. It is already possible to get the low 32 bit part
> of the 64 bit operations for addition, subtraction and multiplication. So
> it is enough to add a few more functions to get the high 32 bit part of 64
> bit additions, subtractions and multiplications. Hence I propose to add the
> following functions:
> >
> > Math.iaddh(lo0, hi0, lo1, hi1) : return the high 32 bit part of the 64
> bit addition of (hi0, lo0) and (hi1, lo1).
> >
> > Math.isubh(lo0, hi0, lo1, hi1) : return the high 32 bit part of the 64
> bit subtraction of (hi0, lo0) and (hi1, lo1).
> >
> > Math.imulh(a, b) : return the high 32 bit part of the signed 64 bit
> product of the 32 bit numbers a and b.
> >
> > Math.imuluh(a, b) : return the high 32 bit part of the unsigned 64 bit
> product of the 32 bit numbers a and b.
> >
> > All these functions convert their argument to 32 bit integers. They
> return a signed 32 bit integer.
> >
> > With these functions, the 64 bit operations are easy to implement :
> >
> > - (hi_res, lo_res) = (hi0, lo0) + (hi1, lo1) (64 bit addition):
> >
> >   lo_res = (lo0 + lo1) | 0;
> >   hi_res = Math.iaddh(lo0, hi0, lo1, hi1);
> >
> > - (hi_res, lo_res) = (hi0, lo0) - (hi1, lo1) (64 bit subtraction):
> >
> >   lo_res = (lo0 - lo1) | 0;
> >   hi_res = Math.isubh(lo0, hi0, lo1, hi1);
> >
> > -  (hi_res, lo_res) = a * b (signed 64 bit product of 32 bit integers):
> >
> >   lo_res = Math.imul(a, b);
> >   hi_res = Math.imulh(a, b);
> >
> > -  (hi_res, lo_res) = a * b (unsigned 64 bit product of 32 bit integers):
> >
> >   lo_res = Math.imul(a, b);
> >   hi_res = Math.imuluh(a, b);
> >
> > -  (hi_res, lo_res) = (hi0, lo0) * (hi1, lo1) (signed 64 bit product of
> 64 bit integers):
> >
> >   lo_res = Math.imul(lo0, lo1);
> >   hi_res = (Math.imulh(lo0, lo1) + Math.imul(lo0, hi1)) | 0;
> >   hi_res = (hi_res + Math.imul(lo1, hi0)) | 0;
> >
> > -  (hi_res, lo_res) = (hi0, lo0) * (hi1, lo1) (unsigned 64 bit product
> of 64 bit integers):
> >
> >   lo_res = Math.imul(lo0, lo1);
> >   hi_res = (Math.imuluh(lo0, lo1) + Math.imul(lo0, hi1)) | 0;
> >   hi_res = (hi_res + Math.imul(lo1, hi0)) | 0;
> >
> > It is easy for the compiler to optimize the code because only 32 bit
> integers are used and because the functions have no side effect. Even if
> the compiler does not remove the duplicate operation for the low 32 bit
> parts, the overhead is very small on a 32 bit CPU (1 more instruction than
> the optimal code).
> >
> > Fabrice.
> >
> > [1] https://www.mail-archive.com/es-discuss%40mozilla.org/msg27237.html
> > ___
> > 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: Math.TAU

[Michael Haufe]

FYI: 


On Sat, Jun 28, 2014 at 9:28 AM, Marius Gundersen 
wrote:

I propose the tau constant be added to the Math object and be defined as
> 2*Math.PI, as described in the tau manifesto:
> http://tauday.com/tau-manifesto
>
> (I couldn't find any discussion about this when searching esdiscuss.org,
> so sorry if this has been discussed before)
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are there any plans to introduce Date/Time literals?

[Michael Haufe]

On Tue, Oct 8, 2013 at 4:43 PM, Andrew Fedoniouk
wrote:

> Quite often Date values are used in data exchanges in form of JS
> literals or JSON.
>
> It would be beneficial if JS (and JSON as derivative) will have an
> ability to represent dates literally  . For example:
>
> {
>eventType: "meeting",
>eventStarts: 2014-11-05T13:15:30Z,
>eventDurationHours: 4
> }
>
> Technically we can allow date/time format using ISO 8601 as it is.
> That will require some additional look-ahead in tokenizer but is
> doable as far as I can tell.
>
> There are other options of course. Just wanted to know if this makes
> sense in principle.
>


http://wiki.ecmascript.org/doku.php?id=discussion:date_literal_syntax

http://wiki.ecmascript.org/doku.php?id=proposals:date_literal_syntax

https://encrypted.google.com/#q=site:https%3A%2F%2Fmail.mozilla.org%2Fpipermail%2Fes-discuss%2F+%22date+literal%22
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: More concise arrow functions

[Michael Haufe]

On Fri, Jul 26, 2013 at 10:50 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> Why do arrow functions require a parameter list and a body? That is, none
> of the following are allowed:
>
> - `=> foo`
> - `bar =>`
> - `=>`
>
> Instead you need the more-verbose
>
> - `() => foo`
> - `bar => {}`
> - `() => {}`
>
> Any chance of relaxing this a bit?
>

A useless parameter is an option:

 _=> 'foo'
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Still waiting for Integer Division

[Michael Haufe]

As long as the domain is consistent with (%) or potentially <
http://wiki.ecmascript.org/doku.php?id=strawman:modulo_operator> I'm
indifferent as my applications are within int32


On Thu, Jul 25, 2013 at 3:03 PM, Brendan Eich  wrote:
[...]

>
> Michael, were you looking for integer-domain double div? I suppose we were
> back in 2008. It's still missing.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Still waiting for Integer Division

[Michael Haufe]

In 2008 I first proposed the addition of an integer division operator to
the language. At the time Brendan noted his regret for this oversight and
desire for the operator as well. I am not seeing this operator available in
the current draft. Can/will this be rectified?

a div b = (a - a % b) / b
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [idea] One more call operator

[Michael Haufe]

Looks more like an architecture problem to me than a language one. There is
plenty of sugar available already

el.on("click", function(e) {});

using the existing arrow syntax:

el.on("click", e => ...)

using a constant instead of a string (it is a flag after all...):

el.on(click, e => ...)

And for your object:

el.myplugin({});

you can use a setter:

el.myplugin = {...}



On Sat, Jul 20, 2013 at 3:05 PM, Andrew Fedoniouk  wrote:

> In typical JS code we can see things like these:
>
> el.on("click", function() {});
> el.myplugin({});
>
> The syntax noise above is obvious I think.
>
> In principle nothing prevents us to modify JS grammar so statements
> above can be rewritten as:
>
> el.on :: "click", function() {};
> el.myplugin :: {};
>
> Or even this: (one token lookahead required)
>
> el.on : "click", function() {};
> el.myplugin : {};
>
> So formal rule for CallExpression may look like as
>
> CallExpression :
>   MemberExpression Arguments or
>   MemberExpression '::' ArgumentList
>
> Not that much but can make it more readable.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)

[Michael Haufe]

The opposite seems to be true:


<
https://github.com/search?q=%22case+NaN%22&type=Everything&repo=&langOverride=&start_value=1
>

On Thu, Jun 14, 2012 at 5:25 PM, Mark S. Miller  wrote:

>
> It's too late for ES6. In order to fix these for ES7, someone would
> need to gather evidence that the web corpus does not depend on the
> current broken behavior.
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Nov 16 meeting notes

[Michael Haufe]

On Wed, Nov 23, 2011 at 12:15 PM, David Herman  wrote:

> Calling it "length" would be a mistake. The word "length" means the
measurement of a sequence:


Of course, the word "magnitude" could consistently apply to arrays, sets,
numbers, maps, and so on. No one would want to write it though...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Sharp Variables

[Michael Haufe]

Is there any plan to standardize Sharp Variables or something similar?

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

Re: Extended Object Literals to review

[Michael Haufe]

On Sat, Mar 12, 2011 at 11:02 AM, Allen Wirfs-Brock
wrote:
[...]
> class c {
>
> }

> class c {
>
> }

> both are equivalent to:

> function c() {};
> c.prototype=Object.create(s.prototype);
[...]

So if "var b = new c", then "b.constructor" will be "s" instead of "c"?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Single frame continuations using yield keyword with generators compatibility proposal

[Michael Haufe]

How does this idea compare to the Reactive Framework extensions that .NET
uses?
Ref:
http://codebetter.com/blogs/matthew.podwysocki/archive/2009/10/14/introducing-the-reactive-framework-part-i.aspx
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Fwd: Addition of a global namespace function?

[Michael Haufe]

On Tue, Dec 1, 2009 at 10:59 PM, Mark A. Ziesemer
wrote:
> I'm sorry - I may very well be missing something, but I don't see how
> this is at all related (?).  What I'm proposing would be somewhat
> related to the YAHOO.namespace function
> (http://developer.yahoo.com/yui/docs/YAHOO.html), though without being
> limited to children of the "YAHOO" global object.  Actually, the YAHOO
> version and others would be able to utilize the version I'm proposing
> within their versions.

If the point is to prevent pollution of global code, the proposed module
system solves that more securely since it can prevents 3rd party code from
doing anything nasty. There is also a related package system they are
discussing:
http://wiki.commonjs.org/wiki/Packages

I've been burned in the past by bad libraries using this idea, so I'm weary
of it admittedly.
Peter Michaux wrote an excellent article on the subject here:
http://peter.michaux.ca/articles/javascript-namespacing
Though I don't agree with his solution of using an underscore naming
convention, I believe he does justice in defining the problem.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Addition of a global namespace function?

[Michael Haufe]

forgot to cc es-discuss.

-- Forwarded message --
From: Michael Haufe 
Date: Tue, Dec 1, 2009 at 10:18 PM
Subject: Re: Addition of a global namespace function?
To: "Mark A. Ziesemer" 


Have you looked at the CommonJS modules proposal?
http://wiki.commonjs.org/wiki/Modules/1.1
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Inherited Privileged Members

[Michael Haufe]

The strawman articles on Object Initialisers look very promising (
http://wiki.ecmascript.org/doku.php?id=strawman:object_initialiser_extensions),
but one issue I didn't see discussed is a solution to enable the inheritance
of privileged members. Currently developers have to redefine accessor
properties and methods on every constructor call to maintain a reference to
the instance private variables. Ex:



function Foo(name, value){
// assume there was argument validation of some form.
var _name = name,
 _value = value;

this.__defineGetter__("name", function(){
return _name;
});
this.__defineSetter__("name", function(v){
//[snip] argument validation
_name = v;
});
this.__defineGetter__("value", function(){
return _value;
});
this.__defineSetter__("value", function(v){
//[snip] argument validation
_value= v;
});
this.toString = function(){
 return _name + ":" + _value";
}
}



This approach can obviously leads to a potentially large amount of memory
consumption. One workaround I've discovered to solve this issue is a pattern
like the following:


var Foo = (function(){
var _refs = [],
_props = [],
_private = {
get : function(o,n){
var i = _refs.indexOf(o);
return ~i ? _props[i][n] : undefined;
},
set : function(o,n,v){
var i = _refs.indexOf(o);
if(~i)
_props[i][n] = v;

var len = _refs.length;
_refs[len] = o;
_props[len] = {};
_props[len][n] = v;
}
};

function Foo(name, value){
_private.set(this, "name", name);
_private.set(this, "value", value);
}

Foo.prototype = {
get name(){
return _private.get(this, "name");
},
set name(v){
_private.set(this, "name", v);
},
get value(){
return _private.get(this, "value");
},
set value(v){
_private.set(this, "value", v);
},
toString : function(){
return _private.get(this,"name") + ":" + _private.get(this,
"value")
}
}

return Foo;
})();

--------

The verbosity is apparent. Has there been any discussion with Object
Initialisers related to this type of problem?

Respectfully,

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

Expression Closures in JS 1.8.1

[Michael Haufe]

The documentation is a little sparse on the Mozilla page:
https://developer.mozilla.org/en/New_in_JavaScript_1.8#Expression_closures
and the wiki doesn't have a page created for it yet on the subject, so I
have a generic question on the grammar:

Is their an ambiguity that prevents the following from being a valid syntax?


function foo();

being the equivalent of

function foo(){ return };

Also, how is it that the following is not misinterpreted to "function() {
return false, true; }"?

addEventListener("click", function() false, true)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Explict Memory Managment

[Michael Haufe]

David Semeria Wrote:

> Why can't the deleted object still exist, with its value set to 'null'?


If you have some large data structure in memory you need to temporarily
remove, why not serialize it and stick in client storage? I believe every
major browser back to IE 5.5 supports this natively in some form I believe.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Some General Nits

[Michael Haufe]

At the request of Dr J R Stockton, I'd like to forward his feedback on the
current specification since he was encountering some difficulties in
contacting the ES5-feedback address:

http://www.merlyn.demon.co.uk/js-262-5.htm
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

"Pretty" function expression names

[Michael Haufe]

I apologize if this double posts, my other mail client seems a bit finicky.

P T Withington wrote:

> Assuming we're allowed to speculate on futures here...

>

> I was thinking about improving debug-ability by adding descriptive names
to function expressions thusly,

>

>   var myFun = function "my description here" (...) { ... };

>

>I.e., be able to use an arbitrary string as the "name" of a function
expression.  It seems to me this would be an unambiguous extension, only
giving up an unlikely syntax error.  >No runtime is required to do anything
with the name, although it would be encouraged to make it available as the
.name property of the function object.  Comments?


>From what I understand arguments.callee is going away. If that is the case,
then from within that function how would I call it?



function "my description here" () {

  ...

  "my description here"(foo)

};



That doesn't seem right, but maybe I'm overlooking something.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES3.1 Draft: 23 Feb 2009 version available

[Michael Haufe]

On page 192-193 of the draft, the first line of  punctuators are 
duplicated at the end of the list on the following page: {}(
)[]


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

Re: object literal types

[Michael Haufe]

Brendan Eich wrote:

On Feb 17, 2009, at 5:07 AM, Michael Haufe wrote:


David-Sarah Hopwood wrote:

"':' (not '=') is used to separate a property name from its value, 
so it

can't also be used for type annotations."


Except in the case of JavaScript's non-standard Sharp Variables 
(https://developer.mozilla.org/En/Sharp_variables_in_JavaScript),


Sharp variables (which I modeled after Common Lisp) are different 
syntax -- their = sign comes *before* the object-type property value 
or outermost object or array initialiser, and the = is preceded by the 
sharp variable name. Also, you can't have any spaces between #n and = 
(for non-negative integer n). There's really no comparison with the 
syntax you sketched.



which is what sparked my question.Is there some ambiguity on why this 
syntax reuse would be off the table?


Yes, there is an ambiguity. See the grammar:

PropertyNameAndValueList:
 PropertyName ':' AssignmentExpression
 PropertyNameAndValueList ',' PropertyName ':' AssignmentExpression

/be





Just the explanation I was looking for, thanks!

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

object literal types

[Michael Haufe]

David-Sarah Hopwood wrote:


"':' (not '=') is used to separate a property name from its value, so it
can't also be used for type annotations."


Except in the case of JavaScript's non-standard Sharp Variables (https://developer.mozilla.org/En/Sharp_variables_in_JavaScript), which is 
what sparked my question.Is there some ambiguity on why this syntax reuse would be off the table?





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

object literal types

[Michael Haufe]

> var Point:object = {
>color:string
>x:double = 20,
>y:double = 50,
>z:double = 3
> }
-

Sorry, typo correction:

var Point:object = {
   color:string = "red",
   x:double = 20,
   y:double = 50,
   z:double = 3
}

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

object literal types

[Michael Haufe]

I was reading through the wiki on the type discussions:

http://wiki.ecmascript.org/doku.php?id=strawman:types
http://wiki.ecmascript.org/doku.php?id=discussion:object_literals_type_of

I realize that some of the content is dated and does not apply to 
Harmony in particular, but  I'm curious to what the proposal is for 
inline types declarations on object literals


This example (from the second url) is straightforward enough:

type Goose = {name: string, email: string, noisy: boolean};
// create a Goose and pass it to f()
f({name: 'Ben', email: 'b...@quack.net', noisy: true} : Goose);

But this example seems a bit lacking:

var white = {r: 0xff, g: 0xff, b: 0xff};  // the type is {*}, not {r:*, g:*, 
b:*, *} or anything like that.


Is there a problem with the following syntax or did I overlook some 
implication/discussion?

var Point:object = {
   color:string
   x:double = 20,
   y:double = 50,
   z:double = 3
}




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

Re: Re: Date literals

[Michael Haufe]

FWIW, VB.NET uses the following syntax for date literals #8/23/1970 
3:45:39AM#


Would that not solve the parsing problem?

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

Sugaring the switch()

[Michael Haufe]

The only reason for the suggestion was to save in typing, code size and to show 
what seems to me to be a better visual organization
of larger lists of comparisons. liorean's example clarified the point pretty 
well as to why my suggestion wouldn't be worth the cost due to the change
in meaning of the expression list. 

Due to the ordering requirement of the list as he had shown, its no wonder I've 
never gotten such a pattern to work as expected. ;)



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

Sugaring the switch()

[Michael Haufe]

I didn't see this mentioned yet, so I'd like to propose implementing a 
feature available in VB.NET that I think would be valuable in ES. Some 
sugar for the switch() block:

switch(foo){
case 1,2,3:
//stuff...
break;
case a,b,c:
//stuff...
break;
}

Would be equivalent to:

switch(foo){
case 1:
//stuff...
break;
case 2:
//stuff...
break;
case 3:
//stuff...
break;
case a:
//stuff...
break;
case b:
//stuff...
break;
case c:
//stuff...
break;
}

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

Re: Attribute defaults for Object.defineProperty

[Michael Haufe]

[[canMod]]

[[elastic]]

[[mutable]] <-- C++ has similar

[[pliant]]

Allen Wirfs-Brock wrote:
> Michael Haufe [mailto:[EMAIL PROTECTED] said:
>   
>> My suggestions:
>>
>> [[IsMod]] "Is capable of being Modified"
>> 
>
> Doesn't follow the "able" convention we established for attributes
>   
>> [[Amendable]]
>> 
>
> Possible confusion with [[Writable]]
>
>   
>> [[Adaptable]]
>> 
>
> Plausible, but when last considered [[Flexible]] won out over it. The common 
> meaning of "configurable" seems a bit closer to the actual semantics than the 
> common meaning of "adaptable"
>   
>> [[Alter]] "Alterable"
>> 
>
> Possible confusion with [[Writable]]
>
> Jeff Watkins <[EMAIL PROTECTED]> said:
>
>   
>> What about Fixed: neither its existence nor its type may be changed?
>> 
>
> We've already consider "Fixed".  Its common meaning and phonics are close 
> enough to "freeze" (which is a term we are using for a related purpose) that 
> we believe people would find the two terms confusing.
>
>   
>>> Although I'd prefer to control Deletable separately from Fixed,
>>>   
>
> Using a single state to control deletability, attribute mutability, and 
> property transformation/replacement is a compromise.  There may be some 
> situations where somebody would really like to control these separately  but 
> it is probably a pretty limited use case.  Individual attributes to control 
> each of these types of transformations make the language and its 
> implementation more complex.  It might also make it more difficult to upgrade 
> existing implementation to 3.1.  As it is, we assume that most 
> implementations can just repurpose their dontDelete bit (if they have one)
>
>   
>> because I'd love to see a delete added to get and set for properties.
>> 
>
> Don't quite understand what you are asking for here?
>
>
>   
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:es-discuss-
>> [EMAIL PROTECTED] On Behalf Of Jeff Watkins
>> Sent: Thursday, August 21, 2008 9:53 PM
>> To: es-discuss@mozilla.org
>> Subject: Re: Attribute defaults for Object.defineProperty
>>
>> What about Fixed: neither its existence nor its type may be changed?
>>
>> Although I'd prefer to control Deletable separately from Fixed,
>> because I'd love to see a delete added to get and set for properties.
>>
>> On 21 Aug, 2008, at 7:37 AM, Neil Mix wrote:
>>
>> 
>>> writable: can be written to
>>> enumerable: can be enumerated
>>> flexible: can be flexed?
>>>
>>> how about configurable?
>>>
>>> On Aug 20, 2008, at 5:31 PM, Allen Wirfs-Brock wrote:
>>>
>>>   
>>>>> From: Brendan Eich [mailto:[EMAIL PROTECTED]
>>>>> Sent: Wednesday, August 20, 2008 11:25 AM
>>>>>   
>>>> [snip]
>>>> 
>>>>> Hi Allen, could you remind me and a few others who were wondering
>>>>> yesterday (sorry I don't remember -- it's in minutes, somewhere)
>>>>>   
>> why
>> 
>>>>> [[Deletable]] was not chosen instead of [[Flexible]]? Thanks.
>>>>>   
>>>> The reason for not using "deletable" was originally explained in the
>>>> message below.  I believe that at one of the phone meetings after
>>>> Oslo we briefly discussed changing it back to "dynamic" or possibly
>>>> something else but the consensus was to stick with "flexible".
>>>>
>>>> 
>>>>> -Original Message-
>>>>> From: [EMAIL PROTECTED] [mailto:es3.x-discuss-
>>>>> [EMAIL PROTECTED] On Behalf Of Allen Wirfs-Brock
>>>>> Sent: Thursday, June 26, 2008 1:39 PM
>>>>> To: [EMAIL PROTECTED] x-discuss; [EMAIL PROTECTED]
>>>>> es4-
>>>>> discuss
>>>>> Subject: RE: "dynamic" attribute nomenclature
>>>>>
>>>>> At today's ES 3.1 conference call (see
>>>>>
>>>>>   
>> http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_24_2008)
>> 
>>>>> we agreed to use the term "Flexible" for the property attribute
>>>>>   
>> that
>> 
>>>>> we recently had been calling "Dynamic" and w

Re: Call for opinions: attribute defaults and renaming "flexible"

[Michael Haufe]

My suggestions:

[[IsMod]] "Is capable of being Modified"

[[Amendable]]

[[Adaptable]]

[[Alter]] "Alterable"

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

Re: local

[Michael Haufe]

"The problem with "let" isn't inexactness or incompleteness, it's
that it's completely off the mark and unrelated, when read as
plain English. All other keywords are closely related to their
in-program semantics in some way. "

As was stated earlier this is debatable. A quick search of the internet 
will show many contexts in which this word is used to denote exactly or 
similarly what it means here.

The Dictionary definition: "To grant the occupancy or use of ..."

Math statements: "Let x = the number of apples in the basket"

Similar use in other programming languages...

Perhaps Brendan or someone else can shed light on the original decision 
making process of "let"'s inclusion in JavaScript 1.7?


Ingvar von Schoultz wrote:
> Steven Johnson wrote:
>> If intuitively-plain English is a requirement, we'll have to change some
>> existing keywords... e.g., I submit that the meaning of "for" has 
>> little to
>> do with typical English usage.
>
> You can read "for..." as and abbreviation of "for each value i
> between 0 and 5, do this."
>
> Keywords don't have to be exact and complete. Given that the
> "for" loop is useful and necessary, expressing it with "for"
> is arguably the closest we can get.
>
> Our starting point must be the constructs that are useful and
> efficient in programming. Given these constructs, we try to find
> suitable words. This means that keywords will necessarily be
> inexact and incomplete.
>
> The problem with "let" isn't inexactness or incompleteness, it's
> that it's completely off the mark and unrelated, when read as
> plain English. All other keywords are closely related to their
> in-program semantics in some way.
>
> Regarding "for", a worse problem is this:
>
> for (var key in map) {...}
>
> for each (var value in map) {...}
>
> Both constructs expand into the same plain-English sentence. I
> think this would be better:
>
> for (var key in map) {...}
>
> for (var value in values map) {...}
>
> for (var [key, value] in [keys, values] map) {...}
>


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

Re: local

[Michael Haufe]

Is it worth changing the name of a statement/expression/definition who's 
labeled intuitiveness is debatable and  which  has been in use since 
JavaScript 1.7? If compatibility is one of the goals wouldn't this 
create more trouble than its worth?



Ingvar von Schoultz wrote:
> The 
> keyword "let" breaks the very valuable JavaScript tradition
> of using intuitively meaningful keywords.
>
> JavaScript uses the word to say "local", but its normal English
> meaning is "allow".
>
> All other JavaScript keywords help you understand the program
> text. Most of them suggest a translation from statement to
> plain English that conveys the meaning reasonably well. The
> totally off-the-mark meaning of "let" makes it strange and
> foreign.
>
> You'd get nicely intuitive plain English if "local" were used
> instead:
>
> if (x == 5)
> {   local y = 3;
> z = x * y;
> }
> for (local Key in List)
> ++List [Key];
>
> Of course one can easily guess intuitively at the historical
> accidents that have led people to use "let" when they really
> mean to say "local". But that's no reason for burdening
> JavaScript with such an off-the-mark word, in my opinion.
>


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

Re: Peano Arithmetic

[Michael Haufe]

Maciej Stachowiak wrote:
>
> On Aug 15, 2008, at 9:17 PM, Michael Haufe wrote:
>
>>
>> --
>>
>> (define (+ x y)
>>(if (= x 0)
>>y
>>(+ (-1+ x) (1+ y
>>
>> function add(x,y) (!x) ? y : add(--x,++y);
>> --
>> I don't claim to be a Scheme expert, but I believe my interpretation 
>> to be correct.
>> I am also aware of the recursion limits of ES having used it for a 
>> number of years.
>> This is for personal study and amusement.
>
> I do claim to be a Scheme expert, and I believe your interpretation is 
> incorrect. The -1+ and 1+ procedures in Scheme return a value derived 
> by adding either -1 or +1 to their argument, but do not mutate their 
> argument - a Scheme procedure cannot do so, only a special form could. 
> However, ECMAScript -- and ++ mutate the referenced location, in 
> addition to returning a value. Preincrement/predecrement operators 
> will at least return the modified instead of the original value, 
> unlike the post versions, but they are still mutators and thus do not 
> match the Scheme seantics.
>
> Regards,
> Maciej
>
>
>

Then I stand corrected, much appreciated.

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

Re: Peano Arithmetic

[Michael Haufe]

Jason Orendorff wrote:
> On Fri, Aug 15, 2008 at 12:22 AM, Michael Haufe <[EMAIL PROTECTED]> wrote:
>   
>> I apologize if this issue was discussed already, I've been unable to
>> find an answer after a few hours of digging and Googling.
>>
>> I was watching some old SICP videos and translating some of the code
>> into JavaScript to see how it compared to Scheme and came across a
>> couple of errors when implementing Peano Arithmetic.
>> 
>
> I think it's a case of mistranslation.  When Scheme says (+ x 1), the
> right ECMAScript translation is x + 1, not x++.  So, in your examples:
>
>   
>>   return add2(x--,y++); //recursion error
>> 
> return add2(x - 1, y + 1);
>
>   
>>   return add3(x,y)++; //error: cannot assign to a function result
>> 
> return add3(x, y) + 1;
>
> Incidentally, ECMAScript does not have Scheme-like tail recursion, so
> the examples from SICP will not all necessarily work.
>
> -j
>
>
>   
@Brendan:
Thanks for the corrections and the reference to rvalues and lvalues, it 
sheds light on quite a few things since I was able to find quite a bit 
of documentation on the terms.

@Jason:
Its from the 2nd SICP video (1b) at 14 minutes:

--

(define (+ x y)
(if (= x 0)
y
(+ (-1+ x) (1+ y

function add(x,y) (!x) ? y : add(--x,++y);
--
I don't claim to be a Scheme expert, but I believe my interpretation to be 
correct. 
I am also aware of the recursion limits of ES having used it for a number of 
years.
This is for personal study and amusement.


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