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

Sam Tobin-Hochstadt samth at
Wed Mar 30 05:06:11 PDT 2011

On Tue, Mar 29, 2011 at 7:08 PM, Allen Wirfs-Brock
<allen at> 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
>> <allen at> 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) {,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.


> 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
samth at

More information about the es-discuss mailing list