default constructors and implicit super() insertion

Lars T Hansen lth at
Wed Jun 27 10:33:41 PDT 2007

On 6/26/07, Graydon Hoare <graydon at> wrote:
> Peter Hall wrote:
> > This syntax doesn't seem to add anything either. It's equivalent to
> > enforcing that you initialize the properties in the constructor (as
> > opposed to doing it in other functions that could be invoked by the
> > constructor). But you could enforce that same restriction without the
> > new syntax. I don't know much about compilers, but is it really too
> > expensive to check that each non-nullable property has been assigned
> > with a value inside the constructor body?
> The committee's feeling was that definite-assignment analysis -- what
> you're describing -- is too expensive, especially for lightweight
> compilers. It might be that any lightweight compiler is actually going
> to run in standard mode all the time anyways, and we might not make
> standard mode obliged to detect failure-to-initialize-non-nullable until
> ctor execution time, in which case there's no "analysis", just a runtime
> bit. I do not have deep feelings either way, and I'm not sure whether we
> decided to support settings lists before or after our notions of strict
> and standard modes had fully formed.
> Anyone want to chime in? I suspect a couple of the people with opinions
> are presently or shortly on vacation...

I expect you're thinking of me and Chris.

Some of the people on this list know I used to work for Opera, and
Opera cares a great deal about keeping JS viable even for the lower
end of the cell phone market (ie, the largest section of it by far).
There are other kinds of devices too that are similarly powered or
have similar constraints on component price (mass-market electronics
like set-top boxes, in-flight entertainment systems, and the
proverbial refrigerator).  These devices have slow CPUs, tiny caches,
small and slow memories, and slow busses; we can argue about whether
they're really equipped to run a full web browser but Opera's
contention is that there is no reason that web technologies should not
accomodate them.  (The lower end of the market is getting better at a
slow pace, too, so don't expect this problem to go away.)  Anyhow, the
consequence is that you want to make web content easy to process, for
both performance reasons and reasons of code size.  For JS, this means
having a straightforward compiler that performs the minimum amount of
analysis, incroporating quick-and-dirty code generation, and so on.
(Strict mode may be beyond such an implementation.)  Definite
assignment analysis is probably only slightly superlinear (I'm not
co-located with my compiler books, but I seem to remember that
definite assignment analysis requires the computation of dominators
and dominator computation is O(n log n) in the size of the flow
graph), but it's another pass added to the compiler.  Some compilers
do on-the-fly code generation and only have one pass anyway and no
notion of "flow graph" to speak of... so the cost *might* be
significant.   If we can find a compromise between usability and
processability then so much the better.

A few more points:

I think Brendan has an important point in that non-nullable
initializers will be clearly visible.  Non-nullability is both strange
and hard to use, and making it syntactically special is not obviously

Speaking as someone who's written a lot of ES4 code so far (and a lot
of C++ before that), the settings are very useful because they allow
the constructor arguments to be named with the same names as the
instance properties for which they provide initial values,

  class C {
    function C(x, y) : x=x, y=y {}
    var x, y;

because of how the scoping is done in settings; for a lot of simple
cases the idiom is powerful and clear (clear enough that adding more
syntax for those simple cases probably does not pay off).

Loading time is important to most web browsers on most platforms;
arguably loading time is dominated by network latency and transfer
time, but let's not make content processing times any higher than
necessary.  I'm worried about several aspects of the language in this
regard already.

Finally, ES programmers get a lot of value from ES canonically being
expressed as source-level text, unlike Java or C#, say.  But it is not
entirely unreasonable for them to pay a little bit in return for that
value, in terms of giving up some conveniences enjoyed by users of
ahead-of-time compiled languages.  ES is growing up and becoming more
complicated, but we're trying to keep the language scripting-like
because this has advantages in itself.

All that said, ES4 is challenging to lightweight implementations, and
it is -- I think -- actually an open question whether a one-pass
non-tree-building reasonably efficient implementation of the language
is possible.  I think it is, but I'm not yet sure it is.  If it turns
out the answer is no, we need to decide whether to remove some
features from ES4 or just abandon that requirement, at which point it
becomes more interesting to consider static properties that require
analysis like definite assignment.

--lars, pretending to be on vacation

More information about the Es4-discuss mailing list