On Thu, Dec 6, 2012 at 5:05 PM, Kevin Newman <capta...@unfocus.com> wrote:
> Here's another whole bunch of polyfills for ES5: > http://www.calormen.com/**polyfill/#polyfill<http://www.calormen.com/polyfill/#polyfill> > > So the idea wouldn't be to integrate these polyfills, as much as target > ES5 directly without worrying too much about IE8 - except to keep in mind > the edge cases of the available polyfills. It should be possible (I think) > to make the compiler work in such a way, that it avoids hitting those edge > cases where things may not work in a polyfilled IE8. > > The end user would be required to find an use a polyfill themselves if > some polyfill code isn't taken under the Apache umbrella. > > Kevin N. I like that idea. But still not all polyfills simulate the intended semantics 100%. The question remains that when we know certain semantics can't be done in a certain browser (like get / set on non-DOM-objects in IE8), should we refrain from using it and risk bad performance in all browsers? On 12/6/12 10:49 AM, Kevin Newman wrote: > >> Maybe it's worth looking at a polyfill for defineProperties in IE8: >> >> https://developer.mozilla.org/**en-US/docs/JavaScript/** >> Reference/Global_Objects/**Object/defineProperties<https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/defineProperties> >> https://developer.mozilla.org/**en-US/docs/JavaScript/** >> Reference/Global_Objects/**Object/keys<https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/keys> >> > So that seems to boil down to always use Object.keys() in generated code of for...in statements. I wonder whether such generated code is efficient... > >> I'm not sure how complete that is though. Does it emulate get/set? or >> would that require all AS3 classes are based off DOM elements (is that even >> viable)? >> > As far as I know, it is not possible to use get/set in IE8, as you cannot make every object a DOM element (even if you could, you would always change its semantics). It would then be easier to generate normal accessor methods, as discussed in this Jangaroo users post<https://groups.google.com/group/jangaroo-users/browse_thread/thread/39afd2e109f92bb9/d866ff395dc5599a>. Bernd Paradies even claimed in his blog that native get/set functions drain performance, but that may have changed since his observation. I'm sure what we should avoid at all cost is to generate different JavaScript code based on the target environment. This makes deployment much more complicated, and bugs that only occur in certain environments are an accident waiting to happen. -Frank-
