Scoped binding of a method to an object

Russell Leggett russell.leggett at gmail.com
Tue Oct 15 07:22:51 PDT 2013


On Tue, Oct 15, 2013 at 3:45 AM, Benjamin (Inglor) Gruenbaum <
inglor at gmail.com> wrote:

> Brendan Eich <brendan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131015/f6b34a31/attachment.html>


More information about the es-discuss mailing list