Mutating primordials and versioning
bedney at technicalpursuit.com
Mon Jan 18 19:34:49 PST 2010
I've been lurking here, just to make sure you all were talking about what I thought you were talking about (didn't know the context under which the term 'primordials' was being used, but I understand it now to be built-in objects, such as Array, Boolean, Function etc. - if this isn't the case, please correct me and ignore the rest of this post).
As co-authors and maintainers of a rather large framework, we've been 'mutating primordials' for over 10 years and have every intention to continue doing so. We do this for 2 main reasons, both of which drive right to the core of our framework:
Bugs: I know that no one here has ever run into a browser bug (tongue firmly in cheek), but the ability to monkey-patch a buggy implementation of a browser native method to fix a bug has allowed us to maintain a consistent API with methods that have already been standardized, but are broken in a particular implementation. For instance, older versions of IE have a problem with negative indexes on methods like slice(). We were able to 'repair' those by monkey-patching. Simple and elegant and, most importantly, no deviation from the well established standard. Bug-free JS implementations exist in the same world as the Tooth Fairy and Sandy Claws.
There seems to be an obsession on this group to try to turn the clock back 10 years and change some of the choices made when ECMAScript ed. 3 was standardized in late 1999. Well, as Austin Powers would say, "That train has sailed". We're gonna be living with E3 from now until the end of time (or until the Web becomes something else entirely). Too much code has been written and, as I've stated on this list before, much of it is behind corporate firewalls, etc. that will never be known, never be 'surveyed', never be 'measured' - and to which the author of said code wandered off 5 years ago.
What we know for sure, regardless of agreement on best practices or coding or lack thereof, is that the work done on ES5 broke our framework. We used 'create' as a wrapper around our own alloc/init sequence and now, thanks to ES5, we've had to rebuild every single type and all calls to our constructors. If there is no plan for a versioning model moving forward, we're anticipating the worst from Harmony.
"The beauty of creating a language, or any tool for that matter, is that people take it and use it in ways you could never imagine...unless of course you go to the trouble to ensure they can't possibly do anything outside of the box you currently imagine."
More information about the es-discuss