Scoped binding of a method to an object

Brendan Eich brendan at
Mon Oct 14 13:05:13 PDT 2013

> Russell Leggett <mailto:russell.leggett at>
> 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 ( 
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:

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).

Libraries such as Underscore push the FP side of the coin; SugarJS, 
Mootools before it, PrototypeJS apart from Object.prototype go the OO way.

> is the proposed bind operator 
> It doesn't use dots, so it won't mask the difference between the 
> normal prototype chain with some additional scoped binding (for good 
> or ill), but along with it comes the clarity and comfort of lexical 
> binding and also the potential use of the module system.
>     import {shuffle,each,filter} from "underscore2";
>     myArray::shuffle();

Not bad, and exactly the kind of design I pointed to in the last post or 
three: new special forms to confine the complexity that killed the SOE 
> And if that isn't enough because you need more polymorphic behavior, I 
> think something like Clojure's 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.


More information about the es-discuss mailing list