Inner functions and outer 'this' (Re: That hash symbol)

[Allen Wirfs-Brock]

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