Scoped binding of a method to an object

Russell Leggett russell.leggett at
Mon Oct 14 14:07:53 PDT 2013

On Mon, Oct 14, 2013 at 4:05 PM, Brendan Eich <brendan at> wrote:

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

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

To be clear, underscore methods as written would not work correctly here.
Those expect the collection as the first argument. What I was proposing to
do with the bind operator would still use "this" to point to the collection
(or whatever the intended target), and thus keep the OO feel, it just
wouldn't use the dot operator, and wouldn't actually modify the prototype
or mess with the lookup chain.

>  is the proposed bind operator**
>> doku.php?id=strawman: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
> strawman.
>> 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.
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
that ever happened. But I guess that's probably a different thread.

- Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list