Look Ma, no "this" (was: ECMAScript Harmony)

Brendan Eich brendan at mozilla.org
Mon Aug 25 14:01:35 PDT 2008

On Aug 25, 2008, at 12:23 PM, Peter Michaux wrote:

>> To refer to the instance in the sugared language, and there are valid
>> use-cases for doing so, we should use |this|. There's no point in
>> introducing a new keyword.
> If there is a need to refer to the instance then "this" does make
> sense. What would be a great success if if there is just no need for
> "this" at all. It certainly seems possible to avoid.

I don't think so. Standard patterns of delegation (visitor, double- 
dispatched dyadic operators) must pass |this| whole and intact.

> Now there is another problem: differentiating between which variables
> are local to the constructor function (that is, transient and garbage
> collected after the constructor function is returned (don't know the
> technical name for these variables))


> and which are properties of the
> resulting returned object.

True temporaries might need explicit block scope to avoid being  
entrained in closures.

> Requiring the programmer to use both "public" and "private" as I did
> below might be a solution (though you thought it is verbose) so that
> it is clear which variables are part of the constructed objects.

But the private vars would not be temporary. They would need to live  
as long as the instance. It seems to me you're mixing lifetime with  

> I suggest at least a couple DOM widgets are used (e.g. tabbed pane,
> dragdrop list, sortable table) as test examples when discussing class
> sugar seriously. The DOM is a big part of the JavaScript world, after
> all.

Great idea.

A lot of Ajax widgets, e.g. Dojo, use their own inheritance models,  
often based on copying properties (sometimes based on prototypes; in  
the case of Dojo's MI, both!). Copying is fine for a zero-inheritance  
classes-as-sugar proposal. The prototype stuff, as Kris points out,  
is different.

> In ES3 a nested function is "private" inside the outer function. So
> there is some sense of "private by default" already.

Lexical scope is great. You have a point.

> No one seemed to response to my post in the thread about modules but
> "module" should not equal "file" as HTTP is still expensive and
> programmers want to concatenate and minify their scripts.

Oh, absolutely. I made the point in several posts, and Ibad picked up  
on it: addressing and loading are outside the core language. The  
inside part that's left is about how the importer names (or does not  
name) the module, how the module provides what the importer requires,  
how eagerly "linking" occurs, whether cycles are allowed (better  
be!), etc.

The upshot is that stuff has to be loaded already. You can't block a  
script mid-evaluation and go service events (violating run-to- 
completion or else locking up some or all UI) to load a remote file  
on demand.

> The only unfortunate thing about "function" is they are not really
> functions.

Ok, I will bite: what are they?

>> Another separable point to debate: resolved, classes should freely  
>> nest (in
>> other classes and functions) and generate new entities each time  
>> they are
>> evaluated. Just like functions (ignoring or removing the joined  
>> function
>> object option from ES3).
> Great!

I phrased this as a proposition to debate pro or con. I didn't mean  
to say it was resolved (but I hope it will be, in Harmony).

>> There are deeper waters to do with types,
> Yes. The parent-child windows issue both declaring the same or
> different "class Foo" seems like an important detail. Perhaps provably
> making nominal types useless or at least as awkward as instanceof?

No, nominal types have their uses. In two disjoint globals, loading  
code defining the same nominal type should result in two types, not  
one -- we don't want to trust the name, or compare the contents. The  
name would simply be qualified by some kind of global identifier or  

Nominal type use-cases for security, which I've mentioned before,  
include auditors (http://www.erights.org/elang/kernel/auditors/) and  
hybrid information flow systems (http://www.ics.uci.edu/~franz/Site/ 
pubs-pdf/C46Prepub.pdf, see figure 3). When you need type relations  
and equivalence based on name bound by special form, it's hard to do  
without. As Mark pointed out in Oslo, nominal types plus lexical  
scope let human and machine auditors know *exactly* what  
implementation(s) a class has.

One can make nominal types via branding in a structural type system.  
There's more to say here, later.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080825/19283a8e/attachment.html 

More information about the Es-discuss mailing list