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))
Temporaries.
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
visibility.
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
pathname.
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.
/be
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
