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 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: 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 a...@weej.com 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: 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 emanuelal...@hotmail.com
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: Array.prototype.contains

[Michael Haufe]

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



On Wed, Jul 23, 2014 at 3:12 PM, Alex Vincent ajvinc...@gmail.com wrote:

 On Wed, Jul 23, 2014 at 11:18 AM, es-discuss-requ...@mozilla.org 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 fpi...@apple.com 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 fabr...@bellard.org 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: http://www.thepimanifesto.com/


On Sat, Jun 28, 2014 at 9:28 AM, Marius Gundersen gunder...@gmail.com
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: 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

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: 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 bren...@mozilla.com 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

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

[Michael Haufe]

The opposite seems to be true:

https://gist.github.com/gists/search?q=%22case+NaN%22x=0y=0

https://github.com/search?q=%22case+NaN%22type=Everythingrepo=langOverride=start_value=1


On Thu, Jun 14, 2012 at 5:25 PM, Mark S. Miller erig...@google.com 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

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
al...@wirfs-brock.comwrote:
[...]
 class c {
proto: s.prototype
 }

 class c {
superclass: s
 }

 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

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

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

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]

 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

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 which subsumes the
 DontDelete attribute.

 From: Allen Wirfs-Brock
 Sent: Wednesday, June 25, 2008 10:37 AM
 To: Lars Hansen; Mark S. Miller
 Cc: [EMAIL PROTECTED] x-discuss
 Subject: dynamic attribute nomenclature

 In Lars's feedback on the the June 11, ES3.1 draft he said:

 p26 8.6.1.  (And throughout the spec) The meaning of dynamic in
 ES4
 is something else (it means a non-fixture property).  It would
 probably
 reduce confusion if the property name Deletable were used here, as
   
 I
 
 though we had agreed previously.

 Dynamic as currently used in ES3.1 means more than just Deletable,
 it
 also means that the property attributes (including the Dynamic
 attribute) can be modified and that it can be transformed  between
 being a data and procedural property. Hence, the name Deletable
 seems
 to imply something too narrow.

 Playing around with the thesaurus, the best positive, active term
 that
 I could find that seems to be a reasonable description of this
 semantics is:
 Alterable

 (other, perhaps less satisfy or otherwise unacceptable alternatives
 include: changeable, mutable, modifiable, flexible, amendable)

 Note this would mean  that data properties would expose properties
 named Writable and Alterable.  My sense is that there is enough
 conceptual  distance between those terms that there won't be too
 much
 confusion.

 Thoughts

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:
 div class=moz-text-flowed style=font-family: -moz-fixedThe 
 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