On Tue, Mar 29, 2011 at 7:08 PM, Allen Wirfs-Brock
<al...@wirfs-brock.com> wrote:
>
> On Mar 29, 2011, at 3:03 PM, Sam Tobin-Hochstadt wrote:
>
>> On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
>> <al...@wirfs-brock.com> wrote:
>>>
>>> JavaScript up to this point seems to have done a pretty good job of
>>> balancing the OO and functional perspective within the language. However, I
>>> think removing the specialness of "this" and the implicit this parameter
>>> may be a step too far that breaks that balance.
>>
>> I disagree with the idea that this is changing the balance. Brendan
>> has responded at length about the proposals, but I wasn't talking at
>> all about removing the distinguished first argument. For example:
>>
>> function f(mythis | x, y) { ... }
>>
>> is very much in the OO tradition of distinguishing the receiver --
>> it's just using lexical scope for disambiguation.
>>
>
> (I think you just reinforced the point I was trying to make. You prioritize
> the use of lexical scoping over a single unambiguous distinguished meaning
> for "this")
>
> I think what would change the balance would be not continuing to have "this"
> serve as the implicit default for the name of the distinguished receiver. In
> particular for
> #f(x,y) {this.foo(x,y)}
> when such definitions occurs in a method like context such as method1,
> method2, and getter below:
First, I think that the major problem here is that we're talking about
two issues together: #-functions and lexical |this|. I think we
should resolve these separately -- there's no reason they have to go
together. That's not to say that I think #-functions without an
implicit bindings are necessarily a bad idea, just that it's a
separate issue.
[snip]
> Optionally allowing explicit use of an alternative receiver name is probably
> acceptable as long as there is a default name. The OO tradition is to
> distinguish the receiver by using a fixed distinguished name, not to provide
> a distinguish place for arbitrarily naming the receiver. Python and various
> lisp object systems allow arbitrary receiver naming, but they have arguably
> never been in the mainstream of object-oriented language design. If you take
> away the special meaning of "this" and you don't have alternative vocabulary
> such as Smalltalk does to talk about the "receiver" of a method then you
> don't have a simple common way to talk about "the object on which the method
> was invoked" and that is an essential concept in the OO tradition.
Second, I think this is taking a pretty narrow view of the OO
tradition. In particular, writing Python (a fairly popular language,
these days :) and Flavors (from the same decade as Smalltalk) out of
the mainstream seems pretty extreme.
--
sam th
sa...@ccs.neu.edu
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
