On Mar 29, 2011, at 3:03 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
> <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
