First of all interesting analogy and read. On Tue, Oct 15, 2013 at 5:22 PM, Russell Leggett <russell.legg...@gmail.com> wrote: > I don't think that the scoped extensions you want are going to happen. I used to like the idea of something like that, but I think it will cause a lot more confusion than its worth.
I'm not convinced either. What I'm going to do for the next couple of days is try to talk to developers about the original _problem_ and see if they even want to solve it. The confusion vs worth is something I'm trying to evaluate. Right now it looks like your estimation is correct but I'm not a fan of partial data. In a few days when I'll have more concrete data. I'll hopefully be smarter in this regard then. > If we didn't have :: (which we don't now), I think people will continue to simply use functions like what underscore does. Personally, I'm ok with that I think using stuff like _.shuffle([1,2,3,4,5]) is not as nice and worse than [1,2,3,4,5].shuffle() . Especially in a more functional interface that does not return the original array (we can even have a generator here). Let's say I have an array [1,2,3,4,5], I want to filter the odd ones, double the remaining elements and then sum the result. (This is obviously not a real use case, but I think we both know there are such use cases) The big issue I see here is chaining. `_.reduce(_.map(_.filter([1,2,3,4,5],x=>x%2 === 0),x=>2*x),(x,y)=>x+y)` Is a lot less readable than `[1,2,3,4,5].filter(x=>x%2===0).map(x=>2*x).reduce((x,y)=>x+y))` The clever `.constructor` trick when extending `Array` solves _that_ use case but like Brendan said it doesn't address some of the ones in the old SOE proposal. Having another invocation syntax like `::` sounds like a __huge__ overhead to me. On Tue, Oct 15, 2013 at 5:22 PM, Russell Leggett <russell.legg...@gmail.com>wrote: > On Tue, Oct 15, 2013 at 3:45 AM, Benjamin (Inglor) Gruenbaum < > ing...@gmail.com> wrote: > >> Brendan Eich <bren...@mozilla.com> wrote: >> > We already have good motivation for :: anyway, as sugar for bind. This >> gives relief to the OO side of the expression problem trade-off by allowing >> lexical bindings to be composed with method calls -- beautiful. No third >> scope axis / lookup parameter! >> >> Yeah, but this doesn't solve the original problem nearly as well IMO >> since it's suddenly different from a normal method call. Having a different >> call operator for scoped extension methods or method invocation seems very >> confusing and counter intuitive for developers. >> >> If I have to remember different invocation mechanics I kind of lost >> already and I don't have the polymorphism I wanted. I completely agree with >> Allen here. >> > > I don't think that the scoped extensions you want are going to happen. I > used to like the idea of something like that, but I think it will cause a > lot more confusion than its worth. My suggestion for the :: binding > operator was basically just trying to leverage an operator that might be > coming anyway and giving it more purpose. I mean, heck, you know JavaScript > programmers, if :: got added to the language, you *know* people will use it > to make nicer looking (subjectively) APIs in the way I'm describing. > > In regards to polymorphism - its not a polymorphic solution out of the > box, or at least - it doesn't provide any affordances for doing > polymorphism, but saying that function calls cannot be polymorphic isn't > true, we're simply flipping around where the polymorphism happens. Yes, I > know this probably sounds like a FP rant, but I think that you can't ignore > the FP side of this (invoking the expression problem again here). OO is > good at adding new cases to the datatype. Functional is good at adding new > functions over the datatype (which is what we're doing here). Trying to get > the best of both worlds likely means playing in the middle. I mean, this > feels like a "you got chocolate in my peanut butter" "you got peanut butter > in may chocolate" moment. You say, "This operator makes my method calls > unintuitive because its not a dot. Method calls should consistently use > dots." I say, "Variables (including function variables) already have well > understood scoping and lookup behavior. The dot operator should have > consistent lookup behavior." Is there a way to marry the functional and OO > to solve this problem? > > If we didn't have :: (which we don't now), I think people will continue to > simply use functions like what underscore does. Personally, I'm ok with > that. If I want to have unscoped extensions and live with the consequences > - I will be happy to use symbols. If I want to make a polyfill, I'll just > do it the same way we've been doing it. But, as much as Allen seems to > accuse me of being an FP guy, I still want to have a thing which feels like > a method to be on the right so I find that using :: (if it existed) would > be a nice compromise. > > Maybe I'll think about what clojure style protocols would look like to > answer some of the polymorphism questions. > > - Russ >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
