ES3.1 questions and issues
Allen.Wirfs-Brock at microsoft.com
Wed Mar 18 22:16:33 PDT 2009
BTW, by "built-in" I didn't mean to imply anything about how the function was implemented but simply whether or not it was the implementation provided version of a function specified by the standard. It occurred to me that this information might be useful to framework builder as part of a feature detection protocol used to decide whether or not to install framework provided versions of some such methods.
>From: Brendan Eich [mailto:brendan at mozilla.com]
>Sent: Wednesday, March 18, 2009 9:22 PM
>To: Tobie Langel
>Cc: Allen Wirfs-Brock; Mark Miller; es-discuss Steen
>Subject: Re: ES3.1 questions and issues
>On Mar 18, 2009, at 11:58 AM, Tobie Langel wrote:
>> On Mar 18, 2009, at 17:20 , Allen Wirfs-Brock wrote:
>>> Would it be useful if there was a way to determine whether nor not
>>> a function was "built-in"?
>> That would be useful outside of the security concerns expressed by
>> Mark. I'm thinking about performance and robustness concerns in JS
>> libraries, for example.
>Can you give an example?
>We're self-hosting native methods that are called built-in by the spec
>in TraceMonkey, and I know V8 original self-hosted some Array and
>String methods. With the right isolation to avoid violating the spec,
>this is a good thing and it should not be prohibited.
>Self-hosting built-ins also should not be the subject of second-
>guessing versionitis in JS libraries. Shades of coding C idioms for
>the microarchitecture of certain revisions of the x86!
More information about the Es-discuss