Personally I'd love to see `Array.empty`, `Function.empty`, `Map.empty`, `String.empty`, etc as nonconfigurable nonwritable frozen/sealed/extensionsPrevented available by default - that might provide the (polyfillable) use case Kyle is currently describing, and might provide a path to making builtins’ prototypes not be instances of the builtin, without breaking code.
That said, I also agree with Kyle that this is something that will certainly break some code. It’s already been decided that `Function.prototype` remains a function - if `Array.prototype` remains an array, are there any other builtins that anybody (Kyle, or otherwise) sees as problematic to continue with the breaking change (ie, continue with making them normal objects)? Kyle, if there was `Array.empty` and `Function.empty`, which would both be polyfillable, would you find those sufficient replacements for your current usages of `Function.prototype` and `Array.prototype`? (my thought process here is, can we provide for this use case without also needing to keep the magic behavior of builtin's prototypes) On Thu, Feb 19, 2015 at 11:05 AM, Kyle Simpson <[email protected]> wrote: > I'm not writing to start or join a debate on the merits of using > `Function.prototype` and `Array.prototype` in the aforementioned ways. I'm > writing to confirm that they are in fact used, not just theoretically made > up. > > I have been writing about and teaching for several years usage of > `Function.prototype` as a (convenience) no-op empty function and > `Array.prototype` as a (convenience) default empty array (not to be > mutated, obviously). The most recent case of me publicly talking about > these techniques is in my recently published book "YDKJS: Types & Grammar": > > > https://github.com/getify/You-Dont-Know-JS/blob/master/types%20&%20grammar/ch3.md#prototypes-as-defaults > > While I can't go back now and get at all those old code bases that I > either consulted on or taught on in workshops, and though that code may > unfortunately not show up in GitHub searches, I assure you that such code > exists. Moreover, I have right now a local (non-GH, for certain reasons) > fork of Esprima that I've been hacking on for about a year, and atm I have > 34 occurrences in it of using `Array.prototype` as a shared empty default > array for starting iterations, etc. > > There is no debate of if it will break code, but rather if it's ok to > break code since the numbers are sufficiently low. Please don't pretend > this is just academic contrarianism at play. > > Furthermore, I would posit that whatever evidence was used to roll back > the `Function.prototype` change -- that is, people who use it as an empty > no-op function -- would be the symmetric evidence, and the nearly identical > mindset, to using `Array.prototype` as a default empty array. That is, I > think there's at least a decent amount of correlation/overlap there. > > However, I'm not seeing or finding the contra-argument of why it's so much > better to justify making this breaking change, nor why it makes more sense > to break `Array.prototype` usage but not `Function.prototype` usage. > > > > --Kyle > > > > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
