Promise resolution handler fires before synchronous constructor stack has finished.

I feel like I'm going crazy, but I have a class hierarchy, and one of the constructors in the hierarchy defers some logic to a microtask, ```js // class Foo constructor() { Promise.resolve().then(() => { this.methodThatSubclassOverrides() }) } methodThatSubclassOverrides() {} ``` and in

RE: Proposal: Typeof Trap

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

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

Re: Lazy Iterators

This was exactly what I proposed a few weeks ago, and received a not so enthusiastic response. Which is strange, as I know many developers who complain exactly about this. In it's current state, map/reduce/filter... functions are irrelevant performance wise in many scenarios in production

RE: Proposal: Typeof Trap

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:

Re: Proposal: Typeof Trap

typeof is very often useful - the only case where it can be arguably considered "broken" is with null. The reason `instanceof` is unreliable is indeed because [[Prototype]]s are mutable - eg `({ __proto__: Array.prototype }) instanceof Array` - but also because it returns a false negative when

Re: Proposal: Typeof Trap

What good is the reliability of something that is more often than not useless? Should there be a typeof hook like Symbol.hasInstance? No. `instanceof` was always sketchy due to the ability to exchange prototypes on an object. When `class` came along, it became effectively broken since `class`

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 >

Re: Lazy Iterators

See https://github.com/tc39/proposal-iterator-helpers On Sat, Jul 27, 2019 at 1:45 PM Artem Kobzar wrote: > The proposal based on really worst thing in JavaScript Arrays. > > If i as developer want to make declarative code with combination of > `Array#map`, `Array#filter` or `Array#reduce` - i

Lazy Iterators

The proposal based on really worst thing in JavaScript Arrays. If i as developer want to make declarative code with combination of `Array#map`, `Array#filter` or `Array#reduce` - i will take a lot of iterations (count of chain element will determinate count of iterations). ```js const arr = [1,

RE: Proposal: Typeof Trap

If it's unfixably broken[1], non-extensible, excessively vague, and non-orthogonal, where does that leave you? [1] From: Jordan Harband Sent: Saturday, July 27, 2019 3:00 PM To: Michael Haufe Cc: ViliusCreator ;

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

RE: Proposal: Typeof Trap

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

RE: Proposal: Typeof Trap

The trend seems to be to rely on typeof less and less as time passes: From the March 2019 Agenda : “Implementation-defined typeof still necessary?”

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’ ```