On Mon, Oct 14, 2013 at 4:05 PM, Brendan Eich <bren...@mozilla.com> wrote:
> Russell Leggett <mailto:russell.leggett@gmail.**com<russell.legg...@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<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. 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 http://wiki.ecmascript.org/** >> doku.php?id=strawman:bind_**operator<http://wiki.ecmascript.org/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 <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. - Russ
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
