On one hand, I agree with Jordan. Don't grief the language due to a bad 3rd party API. Whether we accept it or not, a browser's API is a 3rd party API with respect to Javascript. Otherwise, node would have to include that API to be spec compliant.
On the other hand, let's be a little more pragmatic about it. If that busted-up Web API wasn't important, ES wouldn't be so highly constrained in its changes vs what's running in browsers. On Sun, Jul 28, 2019 at 1:10 AM Jordan Harband <[email protected]> wrote: > The existence of `document.all` (which is now specified in Annex B of the > JS spec) doesn't make `typeof` broken, it makes web browsers broken. > > On Sat, Jul 27, 2019 at 3:42 PM Michael Haufe <[email protected]> > wrote: > >> 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 <[email protected]> >> Sent: Saturday, July 27, 2019 4:42 PM >> To: Michael Haufe <[email protected]> >> Cc: Jordan Harband <[email protected]>; [email protected] >> 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 >> [email protected] >> www.isiahmeadows.com >> >> >> On Sat, Jul 27, 2019 at 5:20 PM Michael Haufe <[email protected]> >> wrote: >> > >> > More than one case: >> > >> > >> > >> > <script> >> > >> > var foo = f() >> > >> > typeof foo // object >> > >> > foo instanceof Object // false >> > >> > >> > >> > var bar = g() >> > >> > typeof bar //undefined >> > >> > bar instanceof Object //true >> > >> > bar() // >> > >> > </script> >> > >> > >> > >> > You could probably guess what the value of foo is. Can you guess what >> the second is in any useful way? >> > >> > >> > >> > From: Jordan Harband <[email protected]> >> > Sent: Saturday, July 27, 2019 3:56 PM >> > To: Michael Haufe <[email protected]> >> > Cc: [email protected] >> > 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 <[email protected]> >> 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 <[email protected]> >> > Sent: Saturday, July 27, 2019 3:00 PM >> > To: Michael Haufe <[email protected]> >> > Cc: ViliusCreator <[email protected]>; >> > [email protected] >> > 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 <[email protected]> >> 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 <[email protected]> >> > Sent: Saturday, July 27, 2019 2:04 PM >> > To: Michael Haufe <[email protected]> >> > Subject: RE: Proposal: Typeof Trap >> > >> > >> > >> > Yes, but it traps `typeof `, not `instanceof`. There’s difference there. >> > >> > _______________________________________________ >> > es-discuss mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> > >> > _______________________________________________ >> > es-discuss mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
