Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at gmail.com
Tue Oct 15 00:45:02 PDT 2013


Brendan Eich <brendan at mozilla.com> wrote:
> We already have good motivation for :: anyway, as sugar for bind. This
gives relief to the OO side of the expression problem trade-off by allowing
lexical bindings to be composed with method calls -- beautiful. No third
scope axis / lookup parameter!

Yeah, but this doesn't solve the original problem nearly as well IMO since
it's suddenly different from a normal method call. Having a different call
operator for scoped extension methods or method invocation seems very
confusing and counter intuitive for developers.

If I have to remember different invocation mechanics I kind of lost already
and I don't have the polymorphism I wanted. I completely agree with Allen
here.

Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

> Now, what might be useful would be :: that has approximately this
semantics ... `   _method ? _method : shuffle}.call(myArray);`

What if the Array has the method further up the prototype chain - like on
Object.prototype and we extend it on Array.prototype? Not to mention that
the performance issues that plagued adding it to the normal invocation
repeat here.

On Mon, Oct 14, 2013 at 11:14 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Right, that is a cost we always consider. Syntax can't be polyfilled.
Once shipped at scale cross-browser, it ends to be "forever".

I've actually went around facebook groups with every day JavaScript
developers yesterday. Probably mostly ones that don't know how to read the
spec (even the really nice and clear ES5 one), but are working as full time
JavaScript developers.

Most of the people I talked to did not seem to appreciate having a breaking
syntax change in order to have scoped extension methods. This is still very
preliminary (~40 people) but I'd really like to get a stronger sense of
what more every day developers think. I'll check around and I'll return
with more significant data.

> You mean the use of 'this.constructor' to make generic Array methods that
create array results in ES1-5 create appropriate subclass instances?

Yeah, I think that's pretty cool - and I agree that if we can get away with
it it's totally worth it :)


On Mon, Oct 14, 2013 at 11:14 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Definitely deep waters here, not one simple thing. Appreciate your
> interactions.
>
> Benjamin (Inglor) Gruenbaum wrote:
>
>> > But there were design issues too. ... user confusion or complexity
>> remains an objection.
>>
>> Yes! This is the thing that bothers me /most/ right now about scoped
>> extension methods. Introducing additional syntax to the language seems like
>> a _huge_ objection to me, the fact that it's another thing to teach
>> programmers and another thing to keep in mind when figuring out scopes when
>> reading new code is a big deal in my opinion.
>>
>
> Right, that is a cost we always consider. Syntax can't be polyfilled. Once
> shipped at scale cross-browser, it ends to be "forever".
>
>
>  Rick and Domenic pointed out to me that one of the bigger use cases I
>> thought having scoped extension methods solves - extending a native object
>> and not having to re-implement methods seems to be already solved by the
>> clever way in the new spec and is under work. There are still interesting
>> problems I think this solves but I'm really not convinced any more that
>> adding the extra syntax is worth it.
>>
>
> You mean the use of 'this.constructor' to make generic Array methods that
> create array results in ES1-5 create appropriate subclass instances?
>
> I still thought that was a breaking change on the web, which we were not
> sure we could get away with. But I agree with you it helps, a lot. Yet, it
> doesn't solve the use-cases at which the SOE strawman was aimed.
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131015/c01b0c99/attachment-0001.html>


More information about the es-discuss mailing list