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
