Inner functions and outer 'this' (Re: That hash symbol)
Allen Wirfs-Brock
allen at wirfs-brock.com
Tue Mar 29 16:08:52 PDT 2011
On Mar 29, 2011, at 3:03 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
> <allen at 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:
function makeChild() {
return {
#method1() {this.method2()}, // assume # allowed as concise obj lit method property def
#method2() {this.getter},
get #getter() {this.parent}, //implicit return
parent = this
}
}
but instead having to say
function makeChild() {
return {
#method1(this|) {this.method2()},
#method2(this|) {this.getter},
get #getter(this|) {this.parent}, //implicit return
parent = this
}
}
or
function Child(parent) {
this.method1 =#(this|) {this.method2()};
this.method2 =#(this|) {this.getter};
this.defineProperty('getter',{get:#getter(this|) {this.parent}});
this.parent = parent;
}
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.
Allen
More information about the es-discuss
mailing list