Proposal: Typeof Trap

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Typeof Trap

ViliusCreator

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’

```


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Typeof Trap

Michael Haufe-2

Symbol.hasInstance exists

 

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/hasInstance

 

/Michael

 

From: es-discuss <[hidden email]> On Behalf Of ViliusCreator
Sent: Saturday, July 27, 2019 1:58 PM
To: [hidden email]
Subject: 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’

```


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Typeof Trap

Michael Haufe-2
In reply to this post by ViliusCreator

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 <[hidden email]>
Sent: Saturday, July 27, 2019 2:04 PM
To: Michael Haufe <[hidden email]>
Subject: RE: Proposal: Typeof Trap

 

Yes, but it traps `typeof `, not `instanceof`. There’s difference there.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Typeof Trap

Jordan Harband
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 2:04 PM
To: Michael Haufe <[hidden email]>
Subject: RE: Proposal: Typeof Trap

 

Yes, but it traps `typeof `, not `instanceof`. There’s difference there.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Typeof Trap

Michael Haufe-2

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 <[hidden email]>
Sent: Saturday, July 27, 2019 3:00 PM
To: Michael Haufe <[hidden email]>
Cc: ViliusCreator <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 2:04 PM
To: Michael Haufe <[hidden email]>
Subject: RE: Proposal: Typeof Trap

 

Yes, but it traps `typeof `, not `instanceof`. There’s difference there.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Typeof Trap

Jordan Harband
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 3:00 PM
To: Michael Haufe <[hidden email]>
Cc: ViliusCreator <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 2:04 PM
To: Michael Haufe <[hidden email]>
Subject: RE: Proposal: Typeof Trap

 

Yes, but it traps `typeof `, not `instanceof`. There’s difference there.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Typeof Trap

Ranando King
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` provides no facility for transfixing the prototype attached to an instance.

On the other hand, `typeof` never had such issues. Unfortunately, when `class` came along, nothing was done to allow `typeof` to treat classes as unique types. That was disappointing. However, adding a hook means that `typeof` would lose its stability and predictability, making it essentially as useless as `instanceof`. If instead, the two changes I just mentioned were made, then `typeof` would even be able to supplant `instanceof` without losing any of its reliability. Just a thought...

On Sat, Jul 27, 2019 at 3:57 PM Jordan Harband <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 3:00 PM
To: Michael Haufe <[hidden email]>
Cc: ViliusCreator <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 2:04 PM
To: Michael Haufe <[hidden email]>
Subject: RE: Proposal: Typeof Trap

 

Yes, but it traps `typeof `, not `instanceof`. There’s difference there.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Typeof Trap

Jordan Harband
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 compared with builtins from different realms (which is why `Array.isArray` is needed.

If the ability you're talking about is to freeze the [[Prototype]] slot on an object without fully freezing, sealing, or preventing extensions, that is something a future proposal is very likely to add.

On Sat, Jul 27, 2019 at 2:06 PM Ranando King <[hidden email]> wrote:
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` provides no facility for transfixing the prototype attached to an instance.

On the other hand, `typeof` never had such issues. Unfortunately, when `class` came along, nothing was done to allow `typeof` to treat classes as unique types. That was disappointing. However, adding a hook means that `typeof` would lose its stability and predictability, making it essentially as useless as `instanceof`. If instead, the two changes I just mentioned were made, then `typeof` would even be able to supplant `instanceof` without losing any of its reliability. Just a thought...

On Sat, Jul 27, 2019 at 3:57 PM Jordan Harband <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 3:00 PM
To: Michael Haufe <[hidden email]>
Cc: ViliusCreator <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 2:04 PM
To: Michael Haufe <[hidden email]>
Subject: RE: Proposal: Typeof Trap

 

Yes, but it traps `typeof `, not `instanceof`. There’s difference there.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Typeof Trap

Michael Haufe-2
In reply to this post by Jordan Harband

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 <[hidden email]>
Sent: Saturday, July 27, 2019 3:56 PM
To: Michael Haufe <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 3:00 PM
To: Michael Haufe <[hidden email]>
Cc: ViliusCreator <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 2:04 PM
To: Michael Haufe <[hidden email]>
Subject: RE: Proposal: Typeof Trap

 

Yes, but it traps `typeof `, not `instanceof`. There’s difference there.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Typeof Trap

Isiah Meadows-2
`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
[hidden email]
www.isiahmeadows.com


On Sat, Jul 27, 2019 at 5:20 PM Michael Haufe <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 3:56 PM
> To: Michael Haufe <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 3:00 PM
> To: Michael Haufe <[hidden email]>
> Cc: ViliusCreator <[hidden email]>; [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 2:04 PM
> To: Michael Haufe <[hidden email]>
> Subject: RE: Proposal: Typeof Trap
>
>
>
> Yes, but it traps `typeof `, not `instanceof`. There’s difference there.
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Typeof Trap

Michael Haufe-2
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 <[hidden email]>
Sent: Saturday, July 27, 2019 4:42 PM
To: Michael Haufe <[hidden email]>
Cc: Jordan Harband <[hidden email]>; [hidden email]
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
[hidden email]
www.isiahmeadows.com


On Sat, Jul 27, 2019 at 5:20 PM Michael Haufe <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 3:56 PM
> To: Michael Haufe <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 3:00 PM
> To: Michael Haufe <[hidden email]>
> Cc: ViliusCreator <[hidden email]>;
> [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 2:04 PM
> To: Michael Haufe <[hidden email]>
> Subject: RE: Proposal: Typeof Trap
>
>
>
> Yes, but it traps `typeof `, not `instanceof`. There’s difference there.
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Typeof Trap

Jordan Harband
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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 4:42 PM
To: Michael Haufe <[hidden email]>
Cc: Jordan Harband <[hidden email]>; [hidden email]
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
[hidden email]
www.isiahmeadows.com


On Sat, Jul 27, 2019 at 5:20 PM Michael Haufe <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 3:56 PM
> To: Michael Haufe <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 3:00 PM
> To: Michael Haufe <[hidden email]>
> Cc: ViliusCreator <[hidden email]>;
> [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 2:04 PM
> To: Michael Haufe <[hidden email]>
> Subject: RE: Proposal: Typeof Trap
>
>
>
> Yes, but it traps `typeof `, not `instanceof`. There’s difference there.
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Typeof Trap

Ranando King
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
Sent: Saturday, July 27, 2019 4:42 PM
To: Michael Haufe <[hidden email]>
Cc: Jordan Harband <[hidden email]>; [hidden email]
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
[hidden email]
www.isiahmeadows.com


On Sat, Jul 27, 2019 at 5:20 PM Michael Haufe <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 3:56 PM
> To: Michael Haufe <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 3:00 PM
> To: Michael Haufe <[hidden email]>
> Cc: ViliusCreator <[hidden email]>;
> [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, July 27, 2019 2:04 PM
> To: Michael Haufe <[hidden email]>
> Subject: RE: Proposal: Typeof Trap
>
>
>
> Yes, but it traps `typeof `, not `instanceof`. There’s difference there.
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Typeof Trap

Isiah Meadows-2
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
[hidden email]
www.isiahmeadows.com

On Sun, Jul 28, 2019 at 10:46 PM Ranando King <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> Sent: Saturday, July 27, 2019 4:42 PM
>>> To: Michael Haufe <[hidden email]>
>>> Cc: Jordan Harband <[hidden email]>; [hidden email]
>>> 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
>>> [hidden email]
>>> www.isiahmeadows.com
>>>
>>>
>>> On Sat, Jul 27, 2019 at 5:20 PM Michael Haufe <[hidden email]> 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 <[hidden email]>
>>> > Sent: Saturday, July 27, 2019 3:56 PM
>>> > To: Michael Haufe <[hidden email]>
>>> > Cc: [hidden email]
>>> > 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 <[hidden email]> 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 <[hidden email]>
>>> > Sent: Saturday, July 27, 2019 3:00 PM
>>> > To: Michael Haufe <[hidden email]>
>>> > Cc: ViliusCreator <[hidden email]>;
>>> > [hidden email]
>>> > 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 <[hidden email]> 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 <[hidden email]>
>>> > Sent: Saturday, July 27, 2019 2:04 PM
>>> > To: Michael Haufe <[hidden email]>
>>> > Subject: RE: Proposal: Typeof Trap
>>> >
>>> >
>>> >
>>> > Yes, but it traps `typeof `, not `instanceof`. There’s difference there.
>>> >
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > [hidden email]
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > [hidden email]
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss