Have you...read Annex B? It's not as large as you might think.
It's worth noting `let[x] = [1]` *was* successfully changed from
setting `let[x]` to `1` to setting `x` to `1`, without breaking the
Web. (ES5 code didn't and couldn't change
`Array.prototype[Symbol.iterator]`.) About the only major additions I
can think of that had to be renamed were `Array.prototype.flat` (many
libraries implemented an incompatible `flatten` method) and
`Array.prototype.includes` (Mootools implemented
`Array.prototype.contains` differently and it broke a lot of users on
old versions of it who wouldn't migrate).
-----
Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
On Sun, Jul 28, 2019 at 10:46 PM Ranando King <king...@gmail.com> wrote:
>
> 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 <ljh...@gmail.com> 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 <t...@thenewobjective.com>
>> 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 <isiahmead...@gmail.com>
>>> Sent: Saturday, July 27, 2019 4:42 PM
>>> To: Michael Haufe <t...@thenewobjective.com>
>>> Cc: Jordan Harband <ljh...@gmail.com>; 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 <t...@thenewobjective.com>
>>> 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 <ljh...@gmail.com>
>>> > Sent: Saturday, July 27, 2019 3:56 PM
>>> > To: Michael Haufe <t...@thenewobjective.com>
>>> > 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 <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 <ljh...@gmail.com>
>>> > Sent: Saturday, July 27, 2019 3:00 PM
>>> > To: Michael Haufe <t...@thenewobjective.com>
>>> > Cc: ViliusCreator <viliuskubilius...@gmail.com>;
>>> > 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 <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 <viliuskubilius...@gmail.com>
>>> > Sent: Saturday, July 27, 2019 2:04 PM
>>> > To: Michael Haufe <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
>>> > 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
>
> _______________________________________________
> 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
