if we'd like to have Array.empty, Function.empty, String.empty and friends, what's wrong with having these as we always had already: as prototypes?
I see just moving and duplicating gotchas, instead of keeping in a well known behavior. This exotic "problem" ... I never really understood it, I blindly trusted it was needed to avoid that kind of invisible Empty constructor Function.prototype inherits from ... which is the Empty we all look for too. Oh well, chicken/eggs inheritance is hard I guess :D Just kidding, if not for good reasons, throw away 60% of Annex E ( also the Array thingy is duplicated in there, it's at the bottom and before too in the HTML version ... just saying ) On Thu, Feb 19, 2015 at 7:33 PM, Kyle Simpson <get...@gmail.com> wrote: > > are there any other builtins that anybody (Kyle, or otherwise) sees as > problematic to continue with the breaking change > > As that book chapter mentions, the only other one I've ever used is > RegExp.prototype (being the default empty match /(?:)/ regular expression). > I have used that only once in my recollection, though I've certainly taught > it so I don't know if others ever did. I would *like* it to keep working, > but it's not a sword I'd die on. AWB has suggested on twitter a patch to > test() and exec() that could hack around that case while letting the ES6 > change go through. > > > 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? > > Yes, a long time back I proposed (not on here, but informally) that there > should be just such a thing Function.empty, but basically just settled back > into using `Function.prototype` since it was already there (and I didn't > conceive of it ever changing). > > The points in favor of either the prototype exotic or an "empty" stand-in > are: 1) convenience 2) possible performance aide to engines. > > > can we provide for this use case > > I certainly wasn't coming to this list to propose new features for ES6, as > late as it is. I only just late last nite found out about this change, and > was just hoping it wasn't too late to abort the change. But if the > fix/compromise is empty stand-ins that give a polyfill path to migration, > I'd be OK with that. > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
