Callable RegExp vs. typeof (was: Re: Draft of Function.prototype.bind.)
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Callable RegExp vs. typeof (was: Re: Draft of Function.prototype.bind.)
by Juriy Zaytsev
::
Rate this Message:
On Aug 13, 2009, at 1:07 PM, Brendan Eich wrote:
There was a discussion of this ticket on Hacker News this morning and we had this slight confusion on whether giving RegExp objects a [[Call]] property is permitted by spec <http://news.ycombinator.com/item?id=760529>. I thought it was, since section 2 clearly states that implementation can introduce its own extensions, but then someone made a point about exact wording in that section and how it seems that implementation can only add properties that spec doesn't mention (i.e. additional ones) and not those that spec mentions (such as [[Call]]) but doesn't specify them on certain objects. Could someone please clarify this? Thank you. -- kangax _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: Callable RegExp vs. typeof (was: Re: Draft of Function.prototype.bind.)
by Brendan Eich-3
::
Rate this Message:
On Aug 13, 2009, at 1:28 PM, Juriy Zaytsev wrote:
> There was a discussion of this ticket on Hacker News this morning > and we had this slight confusion on whether giving RegExp objects a > [[Call]] property is permitted by spec <http://news.ycombinator.com/item?id=760529 > >. I thought it was, since section 2 clearly states that > implementation can introduce its own extensions, but then someone > made a point about exact wording in that section and how it seems > that implementation can only add properties that spec doesn't > mention (i.e. additional ones) and not those that spec mentions > (such as [[Call]]) but doesn't specify them on certain objects. > > Could someone please clarify this? Good point. I seem to recall that David-Sarah Hopwood made it already, but I'm having trouble finding his message right now. ES3 Chapter 16 says: "An implementation may provide additional types, values, objects, properties, and functions beyond those described in this specification. This may cause constructs (such as looking up a variable in the global scope) to have implementation-defined behaviour instead of throwing an error (such as ReferenceError)." As the ycombinator thread correspondent says, this is ambiguous: does "may provide ... properties ... beyond those described by this specification" mean [[Call]] on a native object specified without [[Call]] by ES3 is ok? Or does it mean that only properties whose identifiers are not defined at all for any object may be added? Or should internal properties be excluded in any event? The practical issue of typeof /a/ == "function" being misleading and causing compatibility problems is paramount. Fixing that by ruling that extending RegExp to have a [[Call]] internal property violates ES3 is plausible in theory, but again in practice hard if enough content depends on /a/(s). /be _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: Callable RegExp vs. typeof (was: Re: Draft of Function.prototype.bind.)
by Juriy Zaytsev
::
Rate this Message:
On Aug 13, 2009, at 4:44 PM, Brendan Eich wrote: > On Aug 13, 2009, at 1:28 PM, Juriy Zaytsev wrote: > >> There was a discussion of this ticket on Hacker News this morning >> and we had this slight confusion on whether giving RegExp objects a >> [[Call]] property is permitted by spec <http://news.ycombinator.com/item?id=760529 >> >. I thought it was, since section 2 clearly states that >> implementation can introduce its own extensions, but then someone >> made a point about exact wording in that section and how it seems >> that implementation can only add properties that spec doesn't >> mention (i.e. additional ones) and not those that spec mentions >> (such as [[Call]]) but doesn't specify them on certain objects. >> >> Could someone please clarify this? > > Good point. I seem to recall that David-Sarah Hopwood made it > already, but I'm having trouble finding his message right now. > > ES3 Chapter 16 says: > > "An implementation may provide additional types, values, objects, > properties, and functions beyond those described in this > specification. This may cause constructs (such as looking up a > variable in the global scope) to have implementation-defined > behaviour instead of throwing an error (such as ReferenceError)." > > As the ycombinator thread correspondent says, this is ambiguous: > does "may provide ... properties ... beyond those described by this > specification" mean [[Call]] on a native object specified without > [[Call]] by ES3 is ok? Or does it mean that only properties whose > identifiers are not defined at all for any object may be added? Or > should internal properties be excluded in any event? > > The practical issue of typeof /a/ == "function" being misleading and > causing compatibility problems is paramount. Fixing that by ruling > that extending RegExp to have a [[Call]] internal property violates > ES3 is plausible in theory, but again in practice hard if enough > content depends on /a/(s). Thank you. Whatever the consensus is, could the relevant section in ES5 be made less ambiguous in regards to internal properties (perhaps with an example of [[Call]] being allowed/disallowed on objects that don't explicitly have it)? -- kangax _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
RE: Callable RegExp vs. typeof (was: Re: Draft of Function.prototype.bind.)
by Allen Wirfs-Brock-2
::
Rate this Message:
I think an important part of the "may add" allowance that is somewhat implicit that the only changes to the existing spec. that can be made to accommodate such extension is to cause error conditions to no longer be errors. If your extensions requires/implies other changes to the spec. then it isn't a valid extension but rather a change to the specification.
>-----Original Message----- >From: es-discuss-bounces@... [mailto:es-discuss- >bounces@...] On Behalf Of Brendan Eich >Sent: Thursday, August 13, 2009 1:44 PM >To: Juriy Zaytsev >Cc: es5-discuss@...; es-discuss Steen >Subject: Re: Callable RegExp vs. typeof (was: Re: Draft of >Function.prototype.bind.) > >On Aug 13, 2009, at 1:28 PM, Juriy Zaytsev wrote: > >> There was a discussion of this ticket on Hacker News this morning >> and we had this slight confusion on whether giving RegExp objects a >> [[Call]] property is permitted by spec ><http://news.ycombinator.com/item?id=760529 >> >. I thought it was, since section 2 clearly states that >> implementation can introduce its own extensions, but then someone >> made a point about exact wording in that section and how it seems >> that implementation can only add properties that spec doesn't >> mention (i.e. additional ones) and not those that spec mentions >> (such as [[Call]]) but doesn't specify them on certain objects. >> >> Could someone please clarify this? > >Good point. I seem to recall that David-Sarah Hopwood made it already, >but I'm having trouble finding his message right now. > >ES3 Chapter 16 says: > >"An implementation may provide additional types, values, objects, >properties, and functions beyond those described in this >specification. This may cause constructs (such as looking up a >variable in the global scope) to have implementation-defined behaviour >instead of throwing an error (such as ReferenceError)." > >As the ycombinator thread correspondent says, this is ambiguous: does >"may provide ... properties ... beyond those described by this >specification" mean [[Call]] on a native object specified without >[[Call]] by ES3 is ok? Or does it mean that only properties whose >identifiers are not defined at all for any object may be added? Or >should internal properties be excluded in any event? > >The practical issue of typeof /a/ == "function" being misleading and >causing compatibility problems is paramount. Fixing that by ruling >that extending RegExp to have a [[Call]] internal property violates >ES3 is plausible in theory, but again in practice hard if enough >content depends on /a/(s). > >/be >_______________________________________________ >es-discuss mailing list >es-discuss@... >https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: Callable RegExp vs. typeof (was: Re: Draft of Function.prototype.bind.)
by Lucas Smith-2
::
Rate this Message:
On Aug 13, 2009, at 1:44 PM, Brendan Eich wrote: > ES3 Chapter 16 says: > > "An implementation may provide additional types, values, objects, > properties, and functions beyond those described in this > specification. This may cause constructs (such as looking up a > variable in the global scope) to have implementation-defined > behaviour instead of throwing an error (such as ReferenceError)." > > As the ycombinator thread correspondent says, this is ambiguous: > does "may provide ... properties ... beyond those described by this > specification" mean [[Call]] on a native object specified without > [[Call]] by ES3 is ok? Or does it mean that only properties whose > identifiers are not defined at all for any object may be added? Or > should internal properties be excluded in any event? > > The practical issue of typeof /a/ == "function" being misleading and > causing compatibility problems is paramount. Fixing that by ruling > that extending RegExp to have a [[Call]] internal property violates > ES3 is plausible in theory, but again in practice hard if enough > content depends on /a/(s). Certainly the story is muddied by supporting /a/(str) and reporting typeof /a/ == 'function', but limiting the types of invocation available vs those available to actual functions. No constructor invocation, apply invocation, etc, and in fact hostObj.myRegExpObj(str) 'this' is presumably always the RegExp instance. Comprehending function invocation is confusing enough for js developers. Practically, I see no value in the extension, since it is just shorthand for an existing API. And the fact that it has repercussions elsewhere in the runtime is another point against it. Luke _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: Callable RegExp vs. typeof (was: Re: Draft of Function.prototype.bind.)
by Brendan Eich-3
::
Rate this Message:
On Aug 13, 2009, at 2:07 PM, Luke Smith wrote:
> Practically, I see no value in the extension, since it is just > shorthand for an existing API. And the fact that it has > repercussions elsewhere in the runtime is another point against it. > > Luke You don't need to convince me! But the extension is old, it has grown a user base, and it's now hard to remove. If it spread via Mozilla compatibility due to the way JS is user-agent-forked in Web content, then I'm skeptical that this extension common among non-IE browsers can be revoked in a coordinated and timely way. I don't agree with Mark that fixing Array.prototype.indexOf in draft ES5 to match all the real, shipping implementations is equivalent to revising the typeof sub-spec per David-Sarah's proposal to match callable-RegExp reality. That latter bit of reality is mixed: some browsers (IE versions) do not implement RegExp [[Call]]. Others do, but those others do not all report "function" from typeof /a/. The messiness is not just a difference in degree of de-facto standards agreement compared to indexOf. It also shows greater complexity in the particulars, and in the ambiguous ES3 chapter 16 language. So until just recently (today ;-), I was content to defer David- Sarah's fix while we (Mozilla) tried to find a way to remove callability from our RegExp implementation. But your summary in that webkit.org bug shed light (for me at least) on how far this bad old extension has spread. It's not just us at Mozilla who would have to remove callability, which seems hard enough by itself. Could all the non-IE implementations revoke this extension? Anyway, thanks for your comments in that webkit bug! /be _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
| Free embeddable forum powered by Nabble | Forum Help |
