Transitioning Existing Code to the ES5 Getter/Setter APIs

re: Transitioning Existing Code to the ES5 Getter/Setter APIs

war59312 — Mon, 13 Sep 2010 16:06:11 GMT

@Mark LOL!

re: Transitioning Existing Code to the ES5 Getter/Setter APIs

Mark — Fri, 10 Sep 2010 19:12:04 GMT

You spelled "Typo" wrong in your edit - oh the irony...

re: Transitioning Existing Code to the ES5 Getter/Setter APIs

Johnnyq3 — Wed, 08 Sep 2010 20:16:30 GMT

@Mario

The main reason why IE is using GPU acceleration is to remove the strain that some have on the CPU.

re: Transitioning Existing Code to the ES5 Getter/Setter APIs

steve — Wed, 08 Sep 2010 19:24:46 GMT

@EricLaw - well spotted... it may well be fixed... there is no info on the JScript blog about it (or update to the post) so I figured it still existed... I'll re-test just to be sure though.

re: Transitioning Existing Code to the ES5 Getter/Setter APIs

EricLaw [MSFT] — Wed, 08 Sep 2010 17:49:04 GMT

@Steve,Test: Are you still able to reproduce the problem? I believe that issue was already fixed in an IE8 update (support.microsoft.com/.../976662).

re: Transitioning Existing Code to the ES5 Getter/Setter APIs

Test — Wed, 08 Sep 2010 17:44:31 GMT

Steve-- it's a good bug, but did you file it on Connect? Have you tried it in the Platform Preview build?

re: Transitioning Existing Code to the ES5 Getter/Setter APIs

steve — Wed, 08 Sep 2010 17:41:51 GMT

Double posting here on the IE blog as well as the JScript blog.

IE8's JSON.stringify() has a bug when encoding an empty string "" if that string was collected from a form field's value... where it encodes it as "null".

Can we correctly presume that this will be fixed in IE9?

JScript blog post about the bug: blogs.msdn.com/.../serializing-the-value-of-empty-dom-elements-using-native-json-in-ie8.aspx

And for those that want a good laugh, here is the fix posted by the JScript team:

1.) if (foo === "") foo = ""; //ensure that possibly bogus "" is replaced with a real ""

2.) JSON.stringify(foo); // retuns '""'

Line #1 - yeah that's correct... believe it or not...

Since this is obviously a bug in the JSON.stringify() method... or worse yet the JScript String parsing/casting/? it would be good to get this fixed in IE9 (possibly even backported to IE8)

re: Transitioning Existing Code to the ES5 Getter/Setter APIs

Allen Wirfs-Brock [MSFT] — Wed, 08 Sep 2010 17:24:56 GMT

@Meni

Since you ask, I would classify this post as being more about interoperability than about standards.

I have no problems using the word "Standands". In fact, I use it every day. But as I discussed in blogs.msdn.com/.../chakra-interoperability-means-more-than-just-standards.aspx there is more to achiving interoperability (getting the same code to run in different browsers) than just what is in standards.

re: Transitioning Existing Code to the ES5 Getter/Setter APIs

Allen Wirfs-Brock [MSFT] — Wed, 08 Sep 2010 17:14:45 GMT

@Jeff Walden

Jeff, of course you are correct that there isn't a 100% equivalence in the first two examples. However, since there is no offical spec. for the legacy API and some semantic details actually differ among its browser implementations, it is hard to know with what we would be trying to be 100% equivalent. Regardless, as you infer I was just trying to not keep the article simple. In reality, I suspect that most legacy uses of getter/setter properties don't really care about the enumerability or configurability of the properties. Finally, there are subtle differences in the semantics of legacy pre-ES5 getter/setter properties and ES5 accessor properties. The goal of bridge routines such as these is to support interoperability of common use cases rather than providing a perfect bi-directional emulation of every semantic detail.

Allen

re: Transitioning Existing Code to the ES5 Getter/Setter APIs

Mario — Wed, 08 Sep 2010 15:25:08 GMT

will Internet explorer 9 use less memory and less CPU than internet explorer 8?