On Tue, Jul 24, 2012 at 9:30 AM, thron7 <[email protected]>wrote:
> You're probably right in that it could be hard to cover the spec 100%
> with a polyfill. But then, most vendor implementations don't, so the aim
> might be to have a "good enough" implementation, no?!
>
> So what is your argument here?! Not to provide polyfills at all? Not
> polyfil Function.bind()? Or just caution against making "100%" the
> threshold for implementing them?
>
I'm on the fence. In the past I have argued vehemently against modifying
the prototype of native objects. An early claim of qooxdoo was that it
would never alter native prototypes, yet there were cases where it in fact
did so. In some browsers (IE), functions bound to native objects would be
iterated in a for..in loop, causing the programmer to have to check for
hasOwnProperty() and such, making the programmer's job harder, not easier.
These days, I'm more inclined towards the concept of polyfills. The
browsers have gotten better, and any browser that people should actually be
using these days probably already supports all of these features that would
be polyfilled. The problem comes when one library creates a polyfill that
does not strictly meet the spec, and some other library needs one of the
features that's not implemented in the polyfill, but assumes that if the
function is available, then it is fully implemented. We (qooxdoo
developers) seem to be doing more and more incorporating of external
libraries in our qooxdoo apps, and I do worry that we're going to encounter
compatibility issues with one vendor's polyfill implementation or another's.
I think that my opinion is that if the polyfill can be implemented 100% to
the spec, there should be no problem doing it. If it can't be done 100% to
the spec, it's probably better left without the polyfill.
Derrell
>
>
> T.
>
>
> On 07/24/2012 02:49 PM, Derrell Lipman wrote:
>
> On Tue, Jul 24, 2012 at 7:11 AM, Martin Wittemann <
> [email protected]> wrote:
>
>>
>> 2. We supply a buggy polyfill and another lib will fail
>> Thats nothing we have planed. We should take care of implementing the
>> spec 100%. If thats not possible, we don't add a polyfill because that can
>> cause problems.
>>
>
> Polyfills are not necessarily able to implement the spec 100%. A good
> case in point is Function.bind() for which a pretty good polyfill is
> available, but there are cases that some 3rd party libraries (or the user!)
> may depend on the native functionality and not get it.
>
> Here is an excerpt from
> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind
> which
> discusses some issues of the polyfill for bind(). In particular, the last
> two bullet points are relevant:
>
> Some of the many differences (there may well be others, as this list
> does not seriously attempt to be exhaustive) between this algorithm and the
> specified algorithm are:
>
> - The partial implementation relies Array.prototype.slice,
> Array.prototype.concat, Function.prototype.call and
> Function.prototype.apply, built-in methods to have their original
> values.
> - The partial implementation creates functions that do not have
> immutable "poison pill" caller and arguments properties that throw a
> TypeError upon get, set, or deletion. (This could be added if the
> implementation supports
> Object.defineProperty<https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/defineProperty>,
> or partially implemented [without throw-on-delete behavior] if the
> implementation supports
> the__defineGetter__<https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/defineGetter>
> and
> __defineSetter__<https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/defineSetter>
> extensions.)
> - The partial implementation creates functions that have a prototype
> property.
> (Proper bound functions have none.)
> - The partial implementation creates bound functions whose length property
> does not agree with that mandated by ECMA-262: it creates functions with
> length 0, while a full implementation, depending on the length of the
> target function and the number of pre-specified arguments, may return a
> non-zero length.
>
> If you choose to use this partial implementation, *you must not rely on
> those cases where behavior deviates from ECMA-262, 5th edition!* With
> some care, however (and perhaps with additional modification to suit
> specific needs), this partial implementation may be a reasonable bridge to
> the time when bind() is widely implemented according to the specification.
>
> Cheers,
>
> Derrell
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> qooxdoo-devel mailing
> [email protected]https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
