Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at gmail.com
Sun Oct 13 11:47:41 PDT 2013


> Prollyfilling is great too (perhaps you disagree?), and as its name
suggests it happens *before* the method is added to the spec.

So in your opinion adding a `.shuffle` method to an Array in a library I
ship to users is a good idea if it makes my code clearer and nicer?

I'm not saying I disagree, I'm not one of those people who passes an extra
parameter for `undefined` in a function. I just think it can be very risky.

When I have to work on big code bases that run JavaScript end to end using
multiple frameworks and libraries on both sides, I find that extending
object prototypes can be _very_ risky - and "Prollyfilling" (nice term by
the way) has bitten me before. Sure, in _my_ code it can be very nice, but
I expect libraries to have little to no side effects on my code and that's
exactly the cases it can bite me.

> How exactly did that example "fail"? The differences in detail hardly
matter; PrototypeJS trod a cow-path that ES5 paved. Most users don't worry
about the edge case differences.

I don't think anyone today is doubting the enormous contribution
PrototypeJS had and `.bind` was very useful in it and is very useful in
ES5. However, running into edge cases and getting unexpected results is
something I don't think people appreciate. The SweetJS case is just as
interesting.

There is no doubt some of the most interesting API additions have come from
people extending natives and that says something. However, today when
rather than writing 1000 line pages I see more and more 100 thousand lines
code bases using multiple libraries - side effects that extending natives
sound _very_ scary, and being able to extend the natives in a way that does
not bite me is something I'd _really_ love to play with.

> Don't worry about syntax yet.

Of course, I was just toying around. Like I've said before, pretty much
anyone else in this discussion is more qualified to come with an actual
solution than me.

> This must cost, and it does cost.

Would you mind elaborating on that or linking to relevant discussion about
the last proposal? I'd love to understand the issues involved and get a
better understanding of the challenges something like this would bring.




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

> Benjamin (Inglor) Gruenbaum <mailto:inglor at gmail.com>
>> October 13, 2013 11:00 AM
>>
>> Brendan Eich<brendan at mozilla.com <mailto: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.
>>
>
> Prollyfilling is great too (perhaps you disagree?), and as its name
> suggests it happens *before* the method is 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.
>>
>
> How exactly did that example "fail"? The differences in detail hardly
> matter; PrototypeJS trod a cow-path that ES5 paved. Most users don't worry
> about the edge case differences.
>
>
>  > 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.
>>
>>  Don't worry about syntax yet. The issue in any such semantic extension
> is the required extra lookup parameter: not just contains on the right of
> dot, but the enclosing closure scope.
>
> Unqualified identifiers (ones not used after dot) indeed require lookup
> via closure environments, to the global (let's ignore 'with' and DOM inline
> event handlers).
>
> Dot-qualified identifiers and equivalent bracketed computed property name
> accesses require prototype chain lookup.
>
> No matter the syntax, and independent of details of how one specs it,
> you're proposing a hybrid of the two schemes. This must cost, and it does
> cost.
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131013/ae0d90fb/attachment.html>


More information about the es-discuss mailing list