Scoped binding of a method to an object
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.
> 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.
More information about the es-discuss