Look Ma, no "this" (was: ECMAScript Harmony)
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
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,
> 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
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
> The only unfortunate thing about "function" is they are not really
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
>> object option from ES3).
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...
More information about the Es-discuss