Scoped binding of a method to an object

Brendan Eich brendan at mozilla.com
Mon Oct 14 14:13:08 PDT 2013


> Russell Leggett <mailto:russell.leggett at gmail.com>
> October 14, 2013 2:07 PM
>
> On Mon, Oct 14, 2013 at 4:05 PM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
>
>         Russell Leggett <mailto:russell.leggett at gmail.com
>         <mailto:russell.leggett at gmail.com>>
>         October 14, 2013 12:51 PM
>
>         I get that this isn't really the same, but I think one really
>         viable solution for the scoped method problem (which is really
>         just the expression problem, right?)
>
>
>     The expression problem
>     (http://en.wikipedia.org/wiki/Expression_problem) is about the
>     cross-cutting nature of extension, and how FP and OOP seem to
>     trade off against one another.
>
>     So "scoped object extensions" is not "just the expression
>     problem", but I think it is related as follows:
>
>
> Sorry, I was a bit glib - what I meant was that the ability to add new 
> methods to existing types without modification of the original type 
> and without recompilation is the OO side of it, and that's really what 
> we're talking about here. I brushed with broad strokes, but you 
> clearly see what I mean in your examples. I guess I was trying to 
> invoke all the ideas that have come before in the name of fixing the 
> expression problem and how they would relate to this.

Indeed, the literature is quite rich, and on both FP and OO sides of the 
fence (yes, there is a fence :-P).

> I don't actually think SOE is a good fit for p(r)olyfills, which is a 
> different case than what I would really call the expression problem.

Agreed.

>     If we used only functions (possibly with richer dispatch
>     mechanisms, e.g. multimethods), then lexical scope might be enough
>     to extend without collisions. One just rebinds/renames/shadows to
>     compose functions. Or so I think -- CS gurus should school us here.
>
>     However, JS has an OO flavor, especially in its built-ins
>     (including the DOM). So users want extensions on the right of dot
>     (and after colon in object literals).
>
>
> This is the real trick to why I proposed using the bind operator. The 
> extension methods would take advantage of dynamically bound "this". 
> The methods themselves would be lexically bound - they would simply be 
> variables - however they got there (import, let, destructuring) but 
> the syntactic sugar of :: would allow binding and then calling with a 
> syntax that looks very similar to .

Yes, I got that -- good insight. dherman is championing the bind 
operator for ES7 still.

> To be clear, underscore methods as written would not work correctly here.

Sure, FP-style does not need bind. One point for FP, take that OO! :-D

>         And if that isn't enough because you need more polymorphic
>         behavior, I think something like Clojure's protocols
>         <http://clojure.org/protocols> could be implemented as a
>         library to be used in conjunction.
>
>
>     Clojure wants multimethods too. Some excitement based on my
>     proposal for value object operators.
>
> Yes, although protocols are able to stick with simple single-dispatch 
> based on the datatype extending the protocol. I think this could 
> potentially work with the trademarks proposal 
> <http://wiki.ecmascript.org/doku.php?id=strawman:trademarks> if that 
> ever happened. But I guess that's probably a different thread.

Definitely. Symbol-named brands may suffice for trademarking, but 
dispatch via if-else is still a problem.

/be


More information about the es-discuss mailing list