On 07/23/2012 01:11 PM, John Spackman wrote: > I'm not keen on the idea of modifying built-in classes - AFAICR one of > the original strategies in Qooxdoo was to deliberately /not/ modify the > prototype of built-in classes because of the potential for hard-to-debug > conflicts with other libraries which may be loaded. > > OK, we're unlikely to load (e.g.) Prototype/ExtJS/Dojo as well as > Qooxdoo but it is common for contribs to pull in other libraries with > their own highly developed toolsets like TinyMCE/FCKEditor/etc, which > means Qooxdoo's polyfills could conflict and have compatibility issues. > > It's a little bit more work to type qx.lang.Array.someFunction(myArray…) > but personally I like the idea of being clear and explicit about where > code comes from, and keeping the methods in a separate class (e.g. > qx.lang.Function.bind for example) also makes it perfectly clear what > the implemention is and where to get documentation for it. >
I have to disagree. The point of a Polyfill is to provide a native API if the client doesn't support it. This means using feature detection to determine if the Polyfill is needed and, if so, providing a fully standards-compliant implementation. Any library that fails to do either or both is outdated or plain buggy. I know that in the real world things aren't perfect and sometimes you have to stick with an old library because it's no longer being maintained and/or you can't justify the effort to replace it, but still I don't think that we should drop the Polyfill approach just on the off chance that someone somewhere uses shaky code. In fact, interoperability is a big argument in favor of Polyfills: Why should I have to look up what Array.forEach is called for every library I use? I'd much rather just use the native syntax and be done with it. Regards, Daniel ------------------------------------------------------------------------------ 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
