Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

Also let's not forget that the WindowProxy behavior contradicts the JS object model in that the non-configurable 'something' own property of the window proxy is removed. ___ es-discuss mailing list es-discuss@mozilla.org

smart-mix (mixin library)

As a follow up on my previous mixin proposal and the discussion at ( https://esdiscuss.org/topic/definition-mixins) I published a mixin library on npm: smart-mix (https://www.npmjs.com/package/smart-mix). It: - mixes in public methods - mixes in private methods - allows sharing private state and

What do you call a `function` function?

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

Promise finally

This is an illustration of the current `Promise.prototype.finally` deficiency. In this example, the `incr` method does 2 things. It increases `count` by 1. And increases `methodCallsCount` by 1. At a later point in time, it was decided to add an `incr3` method that did the same, but increase

Re: Promise finally

I made the PR on the ecma repo so that the diff is smaller (since I'm touching more sections than the proposal repo had). https://github.com/tc39/ecma262/pull/1118/files On Sun, Feb 25, 2018 at 5:27 AM, Jordan Harband wrote: > Simply theorizing about how it might be done -

Promise finally

Trying better formatting for esdiscuss.org. ``` CreateResolvingFunctions(promise, finallySourcePromise) update step 3: Let resolve be CreateBuiltinFunction(stepsResolve, « [[Promise]], [[AlreadyResolved]], [[FinallySourcePromise]] »). insert new step 6: Set resolve.[[FinallySourcePromise]] to

Promise finally

If TC39 finds a better solution than the existing one in good time, I don't think it makes sense for it to wait for another year to implement it while having a broken `Promise.prototype.finally` in the browsers. I've been thinking about a solution and, if my solution is correct, the changes are

Promise finally

In other words ```js Promise.resolve().finally(() => {}).then(() => { console.log(1); }); Promise.resolve().then(() => {}).then(() => { console.log(2); }).then(() => { console.log(3); }); ``` prints 2, then 3, then 1. ___ es-discuss mailing list

Promise finally

@Ben Newman There are 2 extra ticks, not just 1. The first one is caused by step 8 of 25.6.5.3.1 and the other one is caused by the fact that the `thenFinally` callback passed in step 7 of 25.6.5.3 returns a promise. I'm wondering if this trade-off is the right one.

Re: Promise finally

e > printing 2? > > 2018年2月23日(金) 19:21 Raul-Sebastian Mihăilă <raul.miha...@gmail.com>: > >> I find it weird that >> >> ```js >> Promise.resolve().finally(() => {}).then(() => { console.log(1); }); >> Promise.resolve().then(() => {}).then(() =

Promise finally

I find it weird that ```js Promise.resolve().finally(() => {}).then(() => { console.log(1); }); Promise.resolve().then(() => {}).then(() => { console.log(2); }); ``` prints 2 and then 1. It would have been possible to spec it in such a way that it would have printed 1 and 2. On the other hand

Object.unfreeze, or similar API

Note that if you want to use the Proxy that way you will probably want to implement the setPrototypeOf and preventExtensions traps as well since, together with set, defineProperty and deleteProperty, they are the traps whose associated internal methods can have side effects on the target when the

Re: Suggestion: Destructuring object initializer.

On Wed, Feb 14, 2018 at 8:25 AM, Bob Myers wrote: > > > For example, I did a quick test comparing `[1, 2]` and `new Array(1, 2)` > and found that performance was identical, in spite of the claimed > inefficiency supposedly introduced by the need to look up `Array`. > > I'm curious

Re: Suggestion: Destructuring object initializer.

On Wed, Feb 14, 2018 at 8:25 AM, Bob Myers wrote: > > > With regard to the issue of the empty object inheriting a setter, my we're > really clutching at straws here. > > Really? I was simply informing you that `Object.assign({}, a, b)` is not equivalent to `{...a, ...b}`.

Suggestion: Destructuring object initializer.

Bob, it's not clear that you understood what Alexander said about the lookup. Object.assign contains 2 names. 'Object' needs to be looked up in all the execution contexts chain, starting with the current execution context, until the global Object function is found. Then the 'assign' property must

PRs policy

A month ago I opened a github issue ( https://github.com/tc39/ecma262/issues/1061) in which I asked whether or not TC39 should have a policy WRT the time frame in which a PR should be merged. I mentioned that there was currently an open PR ( https://github.com/tc39/ecma262/pull/666) which had

Definition mixins

> > > -- Forwarded message -- > From: dante federici > To: es-discuss@mozilla.org > Cc: > Bcc: > Date: Mon, 27 Nov 2017 22:22:11 + > Subject: Re: Re: Definition mixins > I'm having a little trouble parsing your proposed syntax. Can you > formalize

Re: Definition mixins

On Sat, Nov 18, 2017 at 7:53 PM, Bob Myers wrote: > I'm a JS programmer with more decades of experience than I care to > mention, and follow developments in language design closely. Frankly, I > don't understand what you are trying to accomplish or why support for it > needs to be

Re: Definition mixins

On Sat, Nov 18, 2017 at 7:19 PM, Isiah Meadows wrote: > Protocols are not mixins - they're interfaces. They specify minimum > behavior required to implement (their primary focus), not simply extended > behavior. In particular, protocols and mixins would be more

Definition mixins

I updated the proposal with sections for motivation, comparison with other kinds of mixins and protocols. https://github.com/raulsebastianmihaila/ecma262-definition-mixins-proposal The protocols, in their current form, are a naive kind of mixin imlementation. I think it's better to separate

Definition mixins

I need to reword one phrase I wrote: I haven't seen a mixin approach in Javascript similar to this approach or one that doesn't have at least some of the issues I listed in the beginning of this thread and I think it's important to be aware of this when balancing out mixins.

Re: Definition mixins

On Mon, Nov 13, 2017 at 4:25 PM, T.J. Crowder wrote: > > There's an Edit link on messages on esdiscuss.org to let you fix issues > like that (e.g., when there's some esdiscuss.org-specific issue). > Cool, thanks! On Mon, Nov 13, 2017 at 4:48 PM, Isiah Meadows

Definition mixins

The first version is based a hundred percent on concepts and mechanisms already used in Ecma262. (Looks like esdiscuss.org has an issue with percentages). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Definition mixins

For some reason, esdiscuss.org doesn't render my last sentence entirely. This is what I wrote: Did you take a look at the spec I provided? The first version is based 100% on concepts and mechanisms already used in Ecma262. ___ es-discuss mailing list

Re: Definition mixins

On Mon, Nov 13, 2017 at 1:54 PM, Bob Myers wrote: > You should review the TypeScript approach to mixins: > https://www.typescriptlang.org/docs/handbook/mixins.html. > This seems very similar to the naive approach based on Object.assign that I mention in the first message of this

Fwd: Definition mixins

On Mon, Nov 13, 2017 at 10:54 AM, T.J. Crowder wrote: > > > Could you add a "Motivations" section outlining why this is needed and > what alternatives currently exist without new syntax? > > It would be indeed worth adding such a section in the proposal, but for

Definition mixins

I wrote a first draft of the spec for the proposal ( https://github.com/raulsebastianmihaila/ecma262-definition-mixins-proposal). In some cases I'm not certain about the accuracy of the spec and I also cut the corners in a few places. There are 2 versions. The second version only contains the

Re: Definition mixins

On Sun, Nov 5, 2017 at 5:27 PM, kai zhu wrote: > the problem is that you chose to write the chess program in > javascript, instead of say, python or c#. > Kai, you're off-topic. The topic is mixins, not chess games. Please refrain from disrupting this thread.

Definition mixins

Actually the mix obj must be extensible but must be an exotic object so that it's extended only through the mixin mechanism. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Definition mixins

Also, in the same context, for different mixin associated objects there will be different mix objects: ```js function F() { const obj = {}; const obj2 = {}; mixin obj, mixin1; mixin obj2, mixin2; } function mixin1() { return (obj, mix) => {}; } function mixin2() { return (obj, mix)

Definition mixins

One issue that just occurred to me is that we want different families of mixin functions to have access to different mix objects, so that one family doesn't have access to mixin functions from another family (since they're private and the constructor must decide what private data shares with the

Definition mixins

I've been successfully experimenting with a kind of mixins which is different from the naive mixin solution (for instance based on Object.assign) and from functional mixins ( https://medium.com/javascript-scene/functional-mixins-composing-software-ffb66d5e731c). I call them definition mixins. The

Syntax for non-writability and non-configurability

I'd like to propose the following syntax: ```js const obj = { x:| 3, // non-writable property with value 3 y:] 4, // non-configurable property with value 4 z:} 5 // non-writable non-configurable property with value 5 }; ``` Perhaps class fields could also use this syntax. Maybe decorators

Re: Nonconstructors

On Tue, Apr 25, 2017 at 12:15 AM, Tab Atkins Jr. wrote: > > The obvious question is, why do you want to use `this`? > > ~TJ > For cases such as a debounce function: ```js const debounce = (func, delay) => { let timeout; return function (...args) {

Nonconstructors

I have a dilemma. I like how typically the built-in methods are not constructors (like Array.prototype.forEach). I have cases in which I'm creating a function in which I want to use `this` but I would like the function to not be constructible. There are ways of doing this: - checking new.target -

Share a secret across ES6 specific modules, so that other modules cannot access the secret?

If the module that holds the secrets knows how to import the modules that it wants to share the secret with, it can import a certain function from them to share the secret by calling that function and pass the secret. ___ es-discuss mailing list

new [[HasProperty]] invariant for non-extensible objects

To be more explicit, the invariants allow this surprising behavior: ```js Object.preventExtensions(nonStandardExoticObject); Object.isExtensible(nonStandardExoticObject); // false 'foo' in nonStandardExoticObject; // false Object.getOwnPropertyDescriptor(nonStandardExoticObject, 'foo'); //

new [[HasProperty]] invariant for non-extensible objects

If it's not obvious how the state of the target can be checked in order to enforce the invariant, it can be checked as it is checked for all the other invariants, namely in the internal method (in our case the [[HasProperty]] internal method) of the proxy, after the hook (in our case the `has`

Re: new [[HasProperty]] invariant for non-extensible objects

By the time [[HasProperty]] (and `"foo" in p`) finishes, the property doesn't exist anymore, therefore this invariant is not enforced. The invariant is: if the property *exists* and the object is non-extensible, [[HasProperty]] must return true. So, there's no guarantee it returns true if you've

Re: new [[HasProperty]] invariant for non-extensible objects

On Sun, Mar 5, 2017 at 2:52 PM, Oriol _ wrote: > > delete obj.foo; > > When you delete the property of an ordinary object, it stops being 'an observable own property using [[GetOwnProperty]]'. So, `Object.getOwnPropertyDescriptor(obj, "foo")` returns undefined

new [[HasProperty]] invariant for non-extensible objects

Wouldn't it make sense to have the following [[HasProperty]] invariant for all the objects? If the object is non-extensible and P is an observable own property using [[GetOwnProperty]], [[HasProperty]] must return true. The same rule applies for [[OwnPropertyKeys]], where the resulted List must

Do settled promise chain handlers fire in the same turn?

In your example there are 7 promises. 1) `p` 2) `Promise.resolve(console.log('A'))` 3) the promise returned by the first `then` call 4) `Promise.resolve(console.log('B'))` 5) the promise returned by the second `then` call 6) Promise.resolve(console.log('C')) 7) the promise returned by the third

Re: Module singletons

On Thu, Feb 9, 2017 at 4:41 PM, Romuald Quantin wrote: > Usually solved this way: > > - export something to instantiate (a function or a class) > > ``` > module.exports = MyClass; > ``` > - export an object (will be shared, only one instance) > > ``` > module.exports = {}; >

Module singletons

1) My understanding is that a module is a singleton. But how does the spec enforce that? Section 15.2.1.17 HostResolveImportedModule ( https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule) says that the resolving process of a module must be indempotent. 'Each time it is called with a

meeting notes for January 2017?

Can anybody share notes from the January meeting please? Thanks! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

getOwnPropertyDescriptor side effects

I disagree regarding the conformance. According to the conformance section ( https://tc39.github.io/ecma262/#sec-conformance): A conforming implementation of ECMAScript may provide additional types, values, objects, properties, and functions beyond those described in this specification. In

getOwnPropertyDescriptor side effects

Do you mean that an implementation is allowed to return an exotic object from the Error constructor? https://tc39.github.io/ecma262/#sec-error-message The Error constructor calls OrdinaryCreateFromConstructor in step 2. https://tc39.github.io/ecma262/#sec-ordinarycreatefromconstructor

Re: getOwnPropertyDescriptor side effects

on't have to > be stateful, and many of them aren't. > > On Fri, Jan 6, 2017, 14:58 Raul-Sebastian Mihăilă <raul.miha...@gmail.com> > wrote: > >> That sounds like a bug because error objects are ordinary objects and the >> [[GetOwnProperty]] internal method of ord

getOwnPropertyDescriptor side effects

That sounds like a bug because error objects are ordinary objects and the [[GetOwnProperty]] internal method of ordinary objects doesn't have side effects. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Resource management

I agree, but note that a resolved promise is not the same as a fulfilled promise (https://tc39.github.io/ecma262/#sec-promise-objects). On Thu, Dec 29, 2016 at 11:40 AM, Jordan Harband wrote: > You'd need to wrap the body of your `open` function in a try/finally, and > do the

Resource management

Such a protocol would make sense only if new specific syntax was added to the language. But is that really necessary when this can be implemented very easily without new syntax? ```js async function open(file, opts, func) { const fd = await fsp.open(file, opts); await func(fd); await

Re: Proposal: `await [p1, p2]` (equivalent to `await Promise.all([p1, p2])`)

On Wed, Oct 26, 2016 at 10:25 AM, Olivier Lalonde wrote: > I don't think so, what do you mean? > Conceptually, await is similar to Promise.resolve and this similarity is more useful than saving a few keystrokes. ___ es-discuss

Proposal: `await [p1, p2]` (equivalent to `await Promise.all([p1, p2])`)

Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Feature Request: Make ECMA262 a superset of JSON

Note that `["__proto__"]` is different from `__proto__`, while `"__proto__"` is the same as `__proto__`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Why Number(symbol) crashes?

How is NaN useful? Isn't it better to be explicit if you really want a string? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Feature Request: Make ECMA262 a superset of JSON

Disregard my reply as it doesn't make sense. :-) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Feature Request: Make ECMA262 a superset of JSON

Step 4 of http://www.ecma-international.org/ecma-262/7.0/index.html#sec-json.parse says that `__proto__` shouldn't have special meaning when parsing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

The Invariants of the Essential Methods are false in case of reentrancy

In depends on what observing means. In this "inception" kind of observing, you could argue that the property hasn't yet been observed because [[Get]] was called before. ___ es-discuss mailing list es-discuss@mozilla.org

Object.freezing proxies should freeze or throw?

A relevant github issue regarding [[OwnPropertyKeys]] is https://github.com/tc39/ecma262/issues/461 . I also wish [[OwnPropertyKeys]] didn't allow duplicates. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Object.freezing proxies should freeze or throw?

Claude, I don't see how non-extensibility and deleting properties are connected. > ```js > var target = Object.preventExtensions({ x: 1 }) > var proxy = new Proxy(target, { > deleteProperty() { return true } > }) > > Object.isExtensible(proxy) // false > delete proxy.x // true >

Re: Object.freezing proxies should freeze or throw?

call to SetIntegrityLevel ends with a call to > TestIntegrityLevel, which will notice that O is in fact not frozen and thus > cause the call to Object.freeze to fail. > > To summarize: the error here is not with the proxy invariant checks (the > proxy is still unfrozen), but r

Object.freezing proxies should freeze or throw?

Initially posted on github (https://github.com/tc39/ecma262/issues/652), but I think the mailing list is more appropriate. Usually methods on Object that change some internal state of the objects/properties of the objects either succeed or throw. However, Object.freeze can fail to freeze proxies

Code smell? Iterator prototype has iterator method that returns "this"

Indeed, according to http://www.ecma-international.org/ecma-262/7.0/index.html#sec-functionallocate, generators don't have the [[Construct]] internal method. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

The `super` keyword doesn't work as it should?

I wasn't suggesting any mechanism for accomplishing that. Method borrowing is error prone either way. With the current spec, it's risky because this and super basically may use two different prototype chains. Also you may change the prototype of the home object and run into trouble. (In the

Re: The `super` keyword doesn't work as it should?

An alternative would be to consider the object where the method key was found as the home object of the method. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

ES7 - the standard

I see that es7 is now a standard. http://www.ecma-international.org/ecma-262/7.0/index.html Congratulations! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: exports at the top of the file

I don't think it was related to nesting. Anyway, I wrote to him something similar to what I wrote here and later he agreed. Thanks for confirming. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

exports at the top of the file

Douglas Crockford said that eventually JSLint would require exports at the top of the file. However I think there are some issues. If my understanding is correct, ```js export default myConst; const myConst = {}; ``` would throw because when the export is evaluated, in step 2 of the Evaluation

meeting notes for march 2016?

Has anybody managed to take meeting notes during the last meeting? If so, can they please share them? Thank you! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Fwd: Are Zones Global State? Do they provide a dangerous communications channel?

Wouldn't it be enough to prevent access from normal SES realms to the proto-SES realm's Zone primordial in order to keep SES as an ocap environment (by having the global objects from normal SES realms inherit from a proxy of the global object from proto-SES, instead of inheriting directly from the

Class and Property Initialization

Bradley, your example throws an error because `this` is uninitialised when the arrow function is called. (Checked in Firefox). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Primitive values from class constructors

But note that `this` is not a primitive (not even in base constructors). So if a base constructor syntactically returns a primitive, it will semantically return its `this` value, which is an object. So the `this` value will be an object in the derived constructor as well.

Re: Primitive values from class constructors

The rule is that derived constructors throw if they return a primitive different from undefined, so these throw. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Primitive values from class constructors

Yes, both do. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Primitive values from class constructors

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

Re: Primitive values from class constructors

wrote: > Classes aren't intended to be value type factories, so I find this > unlikely to change. > > On Tue, Mar 8, 2016, 15:46 Raul-Sebastian Mihăilă <raul.miha...@gmail.com> > wrote: > >> I see that in step 13 of the [[Construct]] method of ordinary functions ( &g

Primitive values from class constructors

I see that in step 13 of the [[Construct]] method of ordinary functions ( https://tc39.github.io/ecma262/#sec-ecmascript-function-objects-construct-argumentslist-newtarget), the value resulted from the evaluation of the function body is checked and if the constructor is a derived constructor, the

Callable class instances

Forgot about instanceof. ``` var x = 0; function Foo() { if (new.target) { this.i = 0; } else { // I don't know what class.instance is supposed to mean. return x++; } } Object.setPrototypeOf(Foo, null); Foo[Symbol.hasInstance] = () => false; ```

Callable class instances

It seems to me that you are mixing Foo and f. If that's not intended then what you want can be obtained with: ``` var x = 0; function Foo() { if (new.target) { this.i = 0; } else { // I don't know what class.instance is supposed to mean. return x++; } } Object.setPrototypeOf(Foo, null); ```

non-self referencial cyclical promises?

@Benjamin: Your example is different than Bradley's. Should be: ``` var r1, p1 = new Promise(r => r1 = r); var r2, p2 = new Promise(r => r2 = r); ``` ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

non-self referencial cyclical promises?

When I first read that part of the spec, my understanding was that the two promises would cancel each other out by waiting for each other, but without performing an infinite set of PromiseJobs. The resolving functions created in step 1 of 25.4.2.2 that are set as reactions for the other promise

Missing PrepareForTailCall in Function.prototype.apply

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

Missing PrepareForTailCall in Function.prototype.apply

I would file a bug, but I forgot my bugzilla password and bugzilla doesn't send me the email to reset the password. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Missing PrepareForTailCall in Function.prototype.apply

If apply ( http://www.ecma-international.org/ecma-262/6.0/#sec-function.prototype.apply) is called with no argArray, PrepareForTailCall is not performed, unlike in Function.prototype.call, where PrepareForTailCall is always performed. Is it not needed or is it a bug?

Reflection to know if executed within a generator/async ?

Actually I may have misunderstood. I guess you want held to be false in the yielding context. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Reflection to know if executed within a generator/async ?

To Andrea: A function like the one you describe would be practical only if, when called in a sync context, it could wait by blocking, unlike when being called in an async context. Otherwise, it doesn't work: ``` let theValue; function fetchTheValue() { return fetch('/theValue')

Is the informative definition of [[Enumerate]] buggy?

In 9.1.11. it's specified that the iterator returned by the [[Enumerate]] method iterates over String-valued keys. But the informative definition at the end of 9.1.11. is based on whatever is returned by calling Reflect.enumerate on the prototype of the current object, assuming that there is such

enumerate trap invariants

What is the reason for not enforcing invariants on the enumerate trap with respect to non-configurable, enumerable, own properties of (non-extensible) targets? More explicit: why is there no error thrown if such a property is not yielded by the iterator that is returned from the enumerate trap? Is