On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca> wrote: > I am seriously dubious as to whether JSGI should require JavaScript 1.7. > This is not an ECMA standard, and AFAIK is not implemented outside of > Mozilla.
> While I'm a huge Mozilla fan, I don't think making CommonJS specific to > Mozilla implementations of JavaScript is wise.
I agree. I only brought up destructuring to prompt this very conversation.
> It would be nice to be able to implement the standards in any ES3-compliant > JavaScript engine, and there are LOT out there. ES5 should be adopted > quickly as well -- after ratification -- although I would suggest thinking > long and hard about making use of ES5 features in core libraries.
ES3 compliance seems like a good, objective baseline.
What about a shim to implement as much of ES5 as can be monkey-patched on to
ES3? Especially the array extras and the JSON stuff. Is this an unreasonable
requirement?
On Thu, Aug 27, 2009 at 7:17 AM, Dean Landolt <d...@deanlandolt.com> wrote:
> On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca> wrote:
>> I am seriously dubious as to whether JSGI should require JavaScript 1.7.
>> This is not an ECMA standard, and AFAIK is not implemented outside of
>> Mozilla.
>> While I'm a huge Mozilla fan, I don't think making CommonJS specific to
>> Mozilla implementations of JavaScript is wise.
> I agree. I only brought up destructuring to prompt this very conversation.
>> It would be nice to be able to implement the standards in any
>> ES3-compliant JavaScript engine, and there are LOT out there. ES5 should
>> be adopted quickly as well -- after ratification -- although I would suggest
>> thinking long and hard about making use of ES5 features in core libraries.
> ES3 compliance seems like a good, objective baseline.
On Thu, Aug 27, 2009 at 11:28 AM, Mark Porter <dm4m...@gmail.com> wrote:
> What about a shim to implement as much of ES5 as can be monkey-patched on
> to ES3? Especially the array extras and the JSON stuff. Is this an
> unreasonable requirement?
> On Thu, Aug 27, 2009 at 7:17 AM, Dean Landolt <d...@deanlandolt.com>wrote:
>> On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca> wrote:
>>> I am seriously dubious as to whether JSGI should require JavaScript 1.7.
>>> This is not an ECMA standard, and AFAIK is not implemented outside of
>>> Mozilla.
>>> While I'm a huge Mozilla fan, I don't think making CommonJS specific to
>>> Mozilla implementations of JavaScript is wise.
>> I agree. I only brought up destructuring to prompt this very conversation.
>>> It would be nice to be able to implement the standards in any
>>> ES3-compliant JavaScript engine, and there are LOT out there. ES5 should
>>> be adopted quickly as well -- after ratification -- although I would suggest
>>> thinking long and hard about making use of ES5 features in core libraries.
>> ES3 compliance seems like a good, objective baseline.
-- Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
On Thu, Aug 27, 2009 at 8:28 AM, Mark Porter <dm4m...@gmail.com> wrote:
> What about a shim to implement as much of ES5 as can be monkey-patched on
> to ES3? Especially the array extras and the JSON stuff. Is this an
> unreasonable requirement?
I would go further and advocate that CommonJS use ES5 as a base, not ES3. In
that context a shim would be tremendously valuable as it would allow us to
proceed well while waiting for ES5 engines to become available.
> On Thu, Aug 27, 2009 at 7:17 AM, Dean Landolt <d...@deanlandolt.com>wrote:
>> On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca> wrote:
>>> I am seriously dubious as to whether JSGI should require JavaScript 1.7.
>>> This is not an ECMA standard, and AFAIK is not implemented outside of
>>> Mozilla.
>>> While I'm a huge Mozilla fan, I don't think making CommonJS specific to
>>> Mozilla implementations of JavaScript is wise.
>> I agree. I only brought up destructuring to prompt this very conversation.
>>> It would be nice to be able to implement the standards in any
>>> ES3-compliant JavaScript engine, and there are LOT out there. ES5 should
>>> be adopted quickly as well -- after ratification -- although I would suggest
>>> thinking long and hard about making use of ES5 features in core libraries.
>> ES3 compliance seems like a good, objective baseline.
Mark Porter wrote:
> What about a shim to implement as much of ES5 as can be monkey-patched > on to ES3? Especially the array extras and the JSON stuff. Is this an > unreasonable requirement?
> On Thu, Aug 27, 2009 at 7:17 AM, Dean Landolt <d...@deanlandolt.com > <mailto:d...@deanlandolt.com>> wrote:
> On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca
> <mailto:w...@page.ca>> wrote:
> I am seriously dubious as to whether JSGI should require
> JavaScript 1.7. This is not an ECMA standard, and AFAIK is
> not implemented outside of Mozilla.
> While I'm a huge Mozilla fan, I don't think making CommonJS
> specific to Mozilla implementations of JavaScript is wise.
> I agree. I only brought up destructuring to prompt this very
> conversation.
> It would be nice to be able to implement the standards in any
> ES3-compliant JavaScript engine, and there are LOT out
> there. ES5 should be adopted quickly as well -- after
> ratification -- although I would suggest thinking long and
> hard about making use of ES5 features in core libraries.
> ES3 compliance seems like a good, objective baseline.
> Mark Porter wrote:
> > What about a shim to implement as much of ES5 as can be monkey-patched
> > on to ES3? Especially the array extras and the JSON stuff. Is this an
> > unreasonable requirement?
> > On Thu, Aug 27, 2009 at 7:17 AM, Dean Landolt <d...@deanlandolt.com
> > <mailto:d...@deanlandolt.com>> wrote:
> > On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca
> > <mailto:w...@page.ca>> wrote:
> > I am seriously dubious as to whether JSGI should require
> > JavaScript 1.7. This is not an ECMA standard, and AFAIK is
> > not implemented outside of Mozilla.
> > While I'm a huge Mozilla fan, I don't think making CommonJS
> > specific to Mozilla implementations of JavaScript is wise.
> > I agree. I only brought up destructuring to prompt this very
> > conversation.
> > It would be nice to be able to implement the standards in any
> > ES3-compliant JavaScript engine, and there are LOT out
> > there. ES5 should be adopted quickly as well -- after
> > ratification -- although I would suggest thinking long and
> > hard about making use of ES5 features in core libraries.
> > ES3 compliance seems like a good, objective baseline.
-- Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
> Mark Porter wrote: >> What about a shim to implement as much of ES5 as can be monkey-patched >> on to ES3? Especially the array extras and the JSON stuff. Is this an >> unreasonable requirement?
This is what Narwhal does. We're targetting "ES5" compliance, to the extent that it is possible to monkey-patch future-ready functions onto ES3 with the addendum that compliant code may not use for(var iterand in array) notation.
For the migration between ES3 and ES5, this requires a more nuanced approach than one or the other. I would rather not waste time enumerating what portion of ES5 we support, but that is what the situation calls for in the interim. Perhaps we can save some time and absorb some headache for the time being in hope of a brighter future by suggesting that "compliant" implementations must be ES5, and in so far as that our current implementations fall short of ES5, we are not compliant.
Narwhal's Object.freeze transparently returns the same object without modification. That allows us to write code that will work when Object.freeze works, as long as we make no promises that our code is secure on our current implementations. We have a stub for Object.defineProperty that uses engine specific means of defining properties, but has to ignore most of the traits.
I don't think it's been made official, but my understanding was any of
the ES5 methods we could implement easily via JS would be required
(namely the Array methods and JSON, as you mentioned).
> What about a shim to implement as much of ES5 as can be monkey- > patched on to ES3? Especially the array extras and the JSON stuff.
> Is this an unreasonable requirement?
> On Thu, Aug 27, 2009 at 7:17 AM, Dean Landolt <d...@deanlandolt.com>
> wrote:
> On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca> wrote:
> I am seriously dubious as to whether JSGI should require JavaScript
> 1.7. This is not an ECMA standard, and AFAIK is not implemented
> outside of Mozilla.
> While I'm a huge Mozilla fan, I don't think making CommonJS specific
> to Mozilla implementations of JavaScript is wise.
> I agree. I only brought up destructuring to prompt this very
> conversation.
> It would be nice to be able to implement the standards in any ES3- > compliant JavaScript engine, and there are LOT out there. ES5
> should be adopted quickly as well -- after ratification -- although
> I would suggest thinking long and hard about making use of ES5
> features in core libraries.
> ES3 compliance seems like a good, objective baseline.
The only thing I would bring into this discussion is browser support.
It seems like the viability of CommonJS in the browser is on a
separate thought thread right now. And it's not slowing down the
progress of standards and server-side development (and that's good).
But there won't be a fully viable cross-browser ES5 environment for
longer than 2-3 years. To me this means that if you settle on ES5 now
and use it in core features, then CommonJS in the browser won't see as
much adoption.
This thread actually started with regard to JSGI/Jack, which isn't
targeted towards browsers. So maybe this is a moot point. But my
$0.02 cents is that CommonJS should be fully compatible with ES3 for a
while yet. That being said, implementing features of ES5 that are ES3
compliant is a good idea.
:Marco
On Aug 27, 12:48 pm, Kris Kowal <cowbertvon...@gmail.com> wrote:
> > Mark Porter wrote:
> >> What about a shim to implement as much of ES5 as can be monkey-patched
> >> on to ES3? Especially the array extras and the JSON stuff. Is this an
> >> unreasonable requirement?
> This is what Narwhal does. We're targetting "ES5" compliance, to the
> extent that it is possible to monkey-patch future-ready functions onto
> ES3 with the addendum that compliant code may not use for(var iterand
> in array) notation.
> For the migration between ES3 and ES5, this requires a more nuanced
> approach than one or the other. I would rather not waste time
> enumerating what portion of ES5 we support, but that is what the
> situation calls for in the interim. Perhaps we can save some time and
> absorb some headache for the time being in hope of a brighter future
> by suggesting that "compliant" implementations must be ES5, and in so
> far as that our current implementations fall short of ES5, we are not
> compliant.
> Narwhal's Object.freeze transparently returns the same object without
> modification. That allows us to write code that will work when
> Object.freeze works, as long as we make no promises that our code is
> secure on our current implementations. We have a stub for
> Object.defineProperty that uses engine specific means of defining
> properties, but has to ignore most of the traits.
By that, I mean to say that if that shim is required, then coding to ES3
ain't so bad. Most of us have been doing that for years. The new stuff is
dreamy but if I have to develop middleware in ES3 for compatibility, that
isn't a very big restriction. In any case I can require ES5/JS1.7 for my
particular app, if I'm doing something that just won't work without
iterators/generators for instance.
So I guess I'm saying I agree with you that we shouldn't limit CommonJS/JSGI
to ES5/JS1.7 engines
The more accurately, I think we should require ES3 + defined list of ES5
back-ported features.
On Thu, Aug 27, 2009 at 10:14 AM, Wes Garland <w...@page.ca> wrote:
> Mark:
> ES5-which-can-be-implemented-in-ES3 is pretty reasonable: it means you can
> still use an ES3 interpreter.
> Things like destructuring assignment, generators, etc -- new syntax -- will
> pose problems, however.
> Wes
> On Thu, Aug 27, 2009 at 11:28 AM, Mark Porter <dm4m...@gmail.com> wrote:
>> What about a shim to implement as much of ES5 as can be monkey-patched on
>> to ES3? Especially the array extras and the JSON stuff. Is this an
>> unreasonable requirement?
>> On Thu, Aug 27, 2009 at 7:17 AM, Dean Landolt <d...@deanlandolt.com>wrote:
>>> On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca> wrote:
>>>> I am seriously dubious as to whether JSGI should require JavaScript
>>>> 1.7. This is not an ECMA standard, and AFAIK is not implemented outside of
>>>> Mozilla.
>>>> While I'm a huge Mozilla fan, I don't think making CommonJS specific to
>>>> Mozilla implementations of JavaScript is wise.
>>> I agree. I only brought up destructuring to prompt this very
>>> conversation.
>>>> It would be nice to be able to implement the standards in any
>>>> ES3-compliant JavaScript engine, and there are LOT out there. ES5 should
>>>> be adopted quickly as well -- after ratification -- although I would suggest
>>>> thinking long and hard about making use of ES5 features in core libraries.
>>> ES3 compliance seems like a good, objective baseline.
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
-- ---------------------------------------------
Mark Porter
Myna JavaScript Application Server
Easy server-side JS on a Java plaform
http://www.mynajs.org
On Thu, Aug 27, 2009 at 1:08 PM, Tom Robinson <tlrobin...@gmail.com> wrote:
> I don't think it's been made official, but my understanding was any of > the ES5 methods we could implement easily via JS would be required > (namely the Array methods and JSON, as you mentioned).
On Thu, Aug 27, 2009 at 12:18 PM, Mark S. Miller <erig...@google.com> wrote:
> On Thu, Aug 27, 2009 at 8:28 AM, Mark Porter <dm4m...@gmail.com> wrote:
>> What about a shim to implement as much of ES5 as can be monkey-patched on >> to ES3? Especially the array extras and the JSON stuff. Is this an >> unreasonable requirement?
> I would go further and advocate that CommonJS use ES5 as a base, not ES3. > In that context a shim would be tremendously valuable as it would allow us > to proceed well while waiting for ES5 engines to become available.
But as Wes and I pointed out, how do you shim syntax changes (without a preprocessor at least)?
> On Thu, Aug 27, 2009 at 8:28 AM, Mark Porter <dm4m...@gmail.com> wrote:
>> What about a shim to implement as much of ES5 as can be monkey-patched on
>> to ES3? Especially the array extras and the JSON stuff. Is this an
>> unreasonable requirement?
> I would go further and advocate that CommonJS use ES5 as a base, not ES3.
> In that context a shim would be tremendously valuable as it would allow us
> to proceed well while waiting for ES5 engines to become available.
>> On Thu, Aug 27, 2009 at 7:17 AM, Dean Landolt <d...@deanlandolt.com>wrote:
>>> On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca> wrote:
>>>> I am seriously dubious as to whether JSGI should require JavaScript
>>>> 1.7. This is not an ECMA standard, and AFAIK is not implemented outside of
>>>> Mozilla.
>>>> While I'm a huge Mozilla fan, I don't think making CommonJS specific to
>>>> Mozilla implementations of JavaScript is wise.
>>> I agree. I only brought up destructuring to prompt this very
>>> conversation.
>>>> It would be nice to be able to implement the standards in any
>>>> ES3-compliant JavaScript engine, and there are LOT out there. ES5 should
>>>> be adopted quickly as well -- after ratification -- although I would suggest
>>>> thinking long and hard about making use of ES5 features in core libraries.
>>> ES3 compliance seems like a good, objective baseline.
> --
> Cheers,
> --MarkM
-- Sincerely,
Joshaven Potter
"No man making a profession of faith ought to sin, nor one possessed of love
to hate his brother. For He that said, Thou shalt love the Lord thy God,
said also, and thy neighbor as thyself. Those that profess themselves to
be Christs are known not only by what they say, but by what they practice.
For the tree is known by its fruit." -- Ignatius
On Thu, Aug 27, 2009 at 2:04 PM, Dean Landolt<d...@deanlandolt.com> wrote: > On Thu, Aug 27, 2009 at 12:18 PM, Mark S. Miller <erig...@google.com> wrote: >> I would go further and advocate that CommonJS use ES5 as a base, not ES3. >> In that context a shim would be tremendously valuable as it would allow us >> to proceed well while waiting for ES5 engines to become available.
> But as Wes and I pointed out, how do you shim syntax changes (without a > preprocessor at least)?
You don't. But ES5 has very few syntax changes. Just ignore those until we can ignore ES3. Likewise with other more interesting features of ES5 that cannot be practically emulated in ES3. For the moment, as a practical matter, rely only on the parts of ES5 that can be implemented in ES3. But as soon as enough ES5 implementations are available, drop that constraint. This is a transitional issue only.
On Thu, Aug 27, 2009 at 9:48 AM, Kris Kowal<cowbertvon...@gmail.com> wrote: > Perhaps we can save some time and > absorb some headache for the time being in hope of a brighter future > by suggesting that "compliant" implementations must be ES5, and in so > far as that our current implementations fall short of ES5, we are not > compliant.
On Thu, Aug 27, 2009 at 5:04 PM, Dean Landolt <d...@deanlandolt.com> wrote:
> On Thu, Aug 27, 2009 at 12:18 PM, Mark S. Miller <erig...@google.com>wrote:
>> On Thu, Aug 27, 2009 at 8:28 AM, Mark Porter <dm4m...@gmail.com> wrote:
>>> What about a shim to implement as much of ES5 as can be monkey-patched on >>> to ES3? Especially the array extras and the JSON stuff. Is this an >>> unreasonable requirement?
>> I would go further and advocate that CommonJS use ES5 as a base, not ES3. >> In that context a shim would be tremendously valuable as it would allow us >> to proceed well while waiting for ES5 engines to become available.
> But as Wes and I pointed out, how do you shim syntax changes (without a > preprocessor at least)?
> On Thu, Aug 27, 2009 at 9:37 AM, Daniel > Friesen<nadir.seen.f...@gmail.com> wrote: > > I believe we already require JSON. And jsgi requires array.forEach.
> > Mark Porter wrote: > >> What about a shim to implement as much of ES5 as can be monkey-patched > >> on to ES3? Especially the array extras and the JSON stuff. Is this an > >> unreasonable requirement?
> This is what Narwhal does. We're targetting "ES5" compliance, to the > extent that it is possible to monkey-patch future-ready functions onto > ES3 with the addendum that compliant code may not use for(var iterand > in array) notation.
> For the migration between ES3 and ES5, this requires a more nuanced > approach than one or the other. I would rather not waste time > enumerating what portion of ES5 we support, but that is what the > situation calls for in the interim. Perhaps we can save some time and > absorb some headache for the time being in hope of a brighter future > by suggesting that "compliant" implementations must be ES5, and in so > far as that our current implementations fall short of ES5, we are not > compliant.
> Narwhal's Object.freeze transparently returns the same object without > modification. That allows us to write code that will work when > Object.freeze works, as long as we make no promises that our code is > secure on our current implementations. We have a stub for > Object.defineProperty that uses engine specific means of defining > properties, but has to ignore most of the traits.
I love it. But again, what about syntax changes? To say "ES5 compliance" is to say all current implementations should implement new ES5 syntax, e.g. generators and destructuring. Would it be more productive to say CommonJS 1.0 (or whatever) compliance is ES5 sans new syntax. That doesn't preclude devs from using the shiny newness when they know they can (or provide fallbacks).
> I love it. But again, what about syntax changes? To say "ES5 > compliance" is to say all current implementations should implement > new ES5 syntax, e.g. generators and destructuring. Would it be more > productive to say CommonJS 1.0 (or whatever) compliance is ES5 sans > new syntax. That doesn't preclude devs from using the shiny newness > when they know they can (or provide fallbacks).
Next time go read the spec before quoting things about it. Last time i checked ES5 didn't have destructuring assignment or generators - those remain Mozilla only extensions.
-1 for ServerJS requiring ES5. Are there any CommonJS *APIs* (which is the concern of CommonJS) that necessitates ES5? Of course, array vs object JSGI requests both work in ES3, and I haven't seen anything anywhere else that requires ES5. Now obviously module writers are going to want to code to ES5, and they certainly can, but it just means that their modules require both the CommonJS loader and ES5 (Narwhal requiring ES5 or some level ES5 emulation is very reasonable). The desire and motivation to support ES5 is probably much stronger than the desire to have CommonJS compliance, so I don't understand why CommonJS feels compelled to add additional strong arming towards implementors if such a requirement if it is not necessary to define our APIs. APIs should be the focus. Kris
Agreed. I'd like for any ES5 features that can (relatively easily) be
implemented in plain old ES3 to be *required* in CommonJS
implementations. The rest can be optional. For now, at least.
I should be able to assume Array.prototype.map and the rest to are
present. These are very useful and easily implemented methods.
> The only thing I would bring into this discussion is browser support.
> It seems like the viability of CommonJS in the browser is on a
> separate thought thread right now. And it's not slowing down the
> progress of standards and server-side development (and that's good).
> But there won't be a fully viable cross-browser ES5 environment for
> longer than 2-3 years. To me this means that if you settle on ES5 now
> and use it in core features, then CommonJS in the browser won't see as
> much adoption.
> This thread actually started with regard to JSGI/Jack, which isn't
> targeted towards browsers. So maybe this is a moot point. But my
> $0.02 cents is that CommonJS should be fully compatible with ES3 for a
> while yet. That being said, implementing features of ES5 that are ES3
> compliant is a good idea.
> :Marco
> On Aug 27, 12:48 pm, Kris Kowal <cowbertvon...@gmail.com> wrote:
>> On Thu, Aug 27, 2009 at 9:37 AM, Daniel
>> Friesen<nadir.seen.f...@gmail.com> wrote:
>>> I believe we already require JSON. And jsgi requires array.forEach.
>>> Mark Porter wrote:
>>>> What about a shim to implement as much of ES5 as can be monkey- >>>> patched
>>>> on to ES3? Especially the array extras and the JSON stuff. Is
>>>> this an
>>>> unreasonable requirement?
>> This is what Narwhal does. We're targetting "ES5" compliance, to the
>> extent that it is possible to monkey-patch future-ready functions
>> onto
>> ES3 with the addendum that compliant code may not use for(var iterand
>> in array) notation.
>> For the migration between ES3 and ES5, this requires a more nuanced
>> approach than one or the other. I would rather not waste time
>> enumerating what portion of ES5 we support, but that is what the
>> situation calls for in the interim. Perhaps we can save some time
>> and
>> absorb some headache for the time being in hope of a brighter future
>> by suggesting that "compliant" implementations must be ES5, and in so
>> far as that our current implementations fall short of ES5, we are not
>> compliant.
>> Narwhal's Object.freeze transparently returns the same object without
>> modification. That allows us to write code that will work when
>> Object.freeze works, as long as we make no promises that our code is
>> secure on our current implementations. We have a stub for
>> Object.defineProperty that uses engine specific means of defining
>> properties, but has to ignore most of the traits.
I had planned to include these kind of things inside of Wrench.js (which adds various Array/String/etc... handling methods missing from JS and acts as most of MonkeyScript's stdlib, a browser side library, and can be used in any other js environment just by including the file)
I already have it broken up into separate files to break String/Array/etc... up, and broken up to separate features used in later languages (ie: Currently it builds a browser wrench15.js a wrench17.js for Rhino 1.7 and a wrench18.js for SpiderMonkey 1.8+) and separates extras from moz-compat Array methods (most of which became part of ES5 I believe) in a clean way (wrench17.js and wrench18.js also don't include superfluous code when that version already has those implemented).
If anyone wants I can break it down further separating ES5 stuff from other things and provide the ability to build a simple ES5-only build that anyone can just include in their CommonJS implementation to include those.
Tom Robinson wrote:
> Agreed. I'd like for any ES5 features that can (relatively easily) be
> implemented in plain old ES3 to be *required* in CommonJS
> implementations. The rest can be optional. For now, at least.
> I should be able to assume Array.prototype.map and the rest to are
> present. These are very useful and easily implemented methods.
> -tom
> On Aug 27, 2009, at 10:16 AM, Marco Rogers wrote:
>> The only thing I would bring into this discussion is browser support.
>> It seems like the viability of CommonJS in the browser is on a
>> separate thought thread right now. And it's not slowing down the
>> progress of standards and server-side development (and that's good).
>> But there won't be a fully viable cross-browser ES5 environment for
>> longer than 2-3 years. To me this means that if you settle on ES5 now
>> and use it in core features, then CommonJS in the browser won't see as
>> much adoption.
>> This thread actually started with regard to JSGI/Jack, which isn't
>> targeted towards browsers. So maybe this is a moot point. But my
>> $0.02 cents is that CommonJS should be fully compatible with ES3 for a
>> while yet. That being said, implementing features of ES5 that are ES3
>> compliant is a good idea.
>> :Marco
>> On Aug 27, 12:48 pm, Kris Kowal <cowbertvon...@gmail.com> wrote:
>>>>> What about a shim to implement as much of ES5 as can be monkey- >>>>> patched
>>>>> on to ES3? Especially the array extras and the JSON stuff. Is
>>>>> this an
>>>>> unreasonable requirement?
>>> This is what Narwhal does. We're targetting "ES5" compliance, to the
>>> extent that it is possible to monkey-patch future-ready functions
>>> onto
>>> ES3 with the addendum that compliant code may not use for(var iterand
>>> in array) notation.
>>> For the migration between ES3 and ES5, this requires a more nuanced
>>> approach than one or the other. I would rather not waste time
>>> enumerating what portion of ES5 we support, but that is what the
>>> situation calls for in the interim. Perhaps we can save some time
>>> and
>>> absorb some headache for the time being in hope of a brighter future
>>> by suggesting that "compliant" implementations must be ES5, and in so
>>> far as that our current implementations fall short of ES5, we are not
>>> compliant.
>>> Narwhal's Object.freeze transparently returns the same object without
>>> modification. That allows us to write code that will work when
>>> Object.freeze works, as long as we make no promises that our code is
>>> secure on our current implementations. We have a stub for
>>> Object.defineProperty that uses engine specific means of defining
>>> properties, but has to ignore most of the traits.
