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
