Hey, > Polyfills are great where you can choose to load a piece of code to fix > problem and where you know that's going to be the only piece of code > trying to fix that problem. If another polyfil is already in place, the > feature detection can fail. But only in cases where the detection is buggy. If one polyfill finds another polyfill it shouldn't do anything because the feature is already in place and ready to use.
> I think the real world is exactly the point - it obviously isn't perfect > or otherwise we wouldn't have to consider polyfills in the first place and > what concerns me is that when a polyfil causes a conflict it could be > really hard to figure out what's gone wrong, especially where for example > script load order is determined at runtime. The script load order should not be a problem of the app developer. We need to take care of that and make sure you don't have a spot where the polyfills are not in place. > The problem with polyfills for fundamental types like Array and Function > is that they are used by /every/ library, and therefore making a polyfil > could impact everything you use. Exactly. But when they are done right, the just work for every library and thats the goal, to have them work like expected. The same when the function is implemented by the browser. > But if you use another library don't you need to know if they provide a > polyfil anyway? No, a polyfill always check if the feature is already available via feature detection. If another lib offers these feature, were fine to use their implementation. > And how many method names are we talking about here? Just see my initial mail. Its not that much but still a bit. And please keep in mind that were only adding a hand full of methods to those we already have in place! It's not a total new approach in qooxdoo. > Is it really that much effort to type "qx.data.Array.forEach(myVar" vs > "myVar.forEach", when just /one/ side effect could cause a whole day of > debugging? It's not the typing effort. There are two other good reasons. Over time, we can simply remove the polyfills because all browsers not having the feature are gone. This means we have all the code which can potentially be removed in one area. Additionally removing a polyfill is absolutely no work for the app developer which would lead to a lot of work with the other approach. Another good reason for me is to use the knowledge of developers they have from other JavaScript projects. They might have already used the stuff and don't want to learn everything new. Regards, Martin ------------------------------------------------------------------------------ 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
