Brendan Eich <brendan at mozilla.com> wrote:
> No, object detection, polyfilling, and even "prollyfilling" are common
and successful adaptationsp on the Web.

Polyfilling is great _after_ the method has already been added to the spec.
I'm completely fine with adding an Array.prototype.map shim to IE8, the
problem with adding a method that's not on the prototype yet is that it'll
fail in case the spec is different from the implementation I chose. If you
mentioned PrototypeJS, its `.bind` method is one such example.

> Your subject recalls a defunct proposal to add lexically-scoped but
heap-based -- therefore object property-lookup performance hindering --
extension properties.

I have to say this surprises me, a performance issue is the last thing I
expected. What about attaching a prototype as a closure variable, something
(and this is a syntax I __don't__ like) like:
```
(function(use Array){
    Array.prototype.contains = function() { ...
    ...
    // any code here has access to .contains, code that did not originate
here does not have such access, much like a closure.
    // other code is free to use Array without any collisions.
})()
```
Again, I __don't__ like this sort of syntax and I'm __not__ sure about the
semantics here, I just noticed I have this problem - I'm probably not the
most qualified for coming up with the solution out of the amazing minds
right here.

> but for the record, string-equated names have been and will be used to
extend standard built-ins too.

I completely agree here. I'm stoked about symbols just like the next guy
but using symbols here (with the bracket syntax) seems unnatural and not
what I intended to do.

Benjamin Gruenbaum

Kevin Smith <zenparsing at gmail.com> wrote:
> That's what the symbol registry will solve, though.

That's an interesting approach.
However, even if we overlook the (maybe somewhat abusing?) nature of using
something like the symbol registry for coordinating global state like this.
I think this can appear as somewhat of an overkill for something that
sounds to me a common problem and a reasonable use case.

I just thought it would be really nice to have things like
NodeList.prototype.sort or Array.prototype.shuffle without worrying about
conflicts with other libraries or the language itself in a few years.


Benjamin Gruenbaum


On Sun, Oct 13, 2013 at 8:17 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Benjamin (Inglor) Gruenbaum wrote:
>
>> However, this is considered bad practice for many reasons I don't have to
>> repeat here (what if other libraries also override it? What if some user
>> code? What if it makes it to the standard some day?)
>>
>
> Actually, people say extending Object.prototype is bad practive (verboten,
> the original post, IIRC from Arv, said; yes, I recalled correctly:
> http://erik.eae.net/archives/**2005/06/06/22.13.54/<http://erik.eae.net/archives/2005/06/06/22.13.54/>
> ).
>
> Extending Array.prototype is less so, and PrototypeJS did it. Other
> libraries extend built-in prototypes. Some even take care not to jump a
> prior claim.
>
>  The problem is even more prevalent in stuff like
>> String.prototype.contains which we know will be in the next spec - people
>> had little way to add that function to the string prototype /before/ it was
>> adapted to the spec and not get eventually bitten.
>>
>
> No, object detection, polyfilling, and even "prollyfilling" are common and
> successful adaptationsp on the Web.
>
> Symbols help but (without dot syntax) also hurt. We'll see how much use
> they get in the future, but for the record, string-equated names have been
> and will be used to extend standard built-ins too.
>
> Your subject recalls a defunct proposal to add lexically-scoped but
> heap-based -- therefore object property-lookup performance hindering --
> extension properties. This proposal died precise because of the performance
> problem.
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131013/a2279b87/attachment-0001.html>

Brendan Eich <brendan at mozilla.com> wrote:
> No, object detection, polyfilling, and even "prollyfilling" are common

and successful adaptationsp on the Web.

Polyfilling is great _after_ the method has already been added to the spec.
I'm completely fine with adding an Array.prototype.map shim to IE8, the
problem with adding a method that's not on the prototype yet is that it'll
fail in case the spec is different from the implementation I chose. If you
mentioned PrototypeJS, its `.bind` method is one such example.

> Your subject recalls a defunct proposal to add lexically-scoped but

heap-based -- therefore object property-lookup performance hindering --
extension properties.

I have to say this surprises me, a performance issue is the last thing I
expected. What about attaching a prototype as a closure variable, something
(and this is a syntax I __don't__ like) like:
```
(function(use Array){
    Array.prototype.contains = function() { ...
    ...
    // any code here has access to .contains, code that did not originate
here does not have such access, much like a closure.
    // other code is free to use Array without any collisions.
})()
```
Again, I __don't__ like this sort of syntax and I'm __not__ sure about the
semantics here, I just noticed I have this problem - I'm probably not the
most qualified for coming up with the solution out of the amazing minds
right here.

> but for the record, string-equated names have been and will be used to

extend standard built-ins too.

I completely agree here. I'm stoked about symbols just like the next guy
but using symbols here (with the bracket syntax) seems unnatural and not
what I intended to do.

Kevin Smith <zenparsing at gmail.com> wrote:
> That's what the symbol registry will solve, though.

That's an interesting approach.
However, even if we overlook the (maybe somewhat abusing?) nature of using
something like the symbol registry for coordinating global state like this.
I think this can appear as somewhat of an overkill for something that
sounds to me a common problem and a reasonable use case.

I just thought it would be really nice to have things like
NodeList.prototype.sort or Array.prototype.shuffle without worrying about
conflicts with other libraries or the language itself in a few years.