default constructors and implicit super() insertion
brendan at mozilla.org
Wed Jun 27 13:44:10 PDT 2007
[Jumping in on one point only, I'll hope to help Lars get back to
vacation so he can reply in full later :-P]
On Jun 27, 2007, at 12:00 PM, Peter Hall wrote:
>> 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.)
> I was under the impression that this discussion would not apply in
> non-strict mode. Would it be an error to not initialize a non-nullable
> variable in non-strict mode?
Yes, otherwise you have just renamed NPE to UE for no win, and then
what's the point of non-nullable types.
The intuition should be familiar to anyone who has written fast low-
level C or C++ code. Your instance has pointer members, they are
guaranteed non-null by the constructor or an initialization routine,
any failure during constructor/initialization propagates and disposes
of the half-initialized newborn. Thus all methods post initialization
need never check for null, and you never get a null pointer crash.
This is common, even required (certainly in kernel land -- I used to
be a Unix kernel hacker).
Non-nullable types should capture this use case. They ought to
eliminate stupid NPEs that I've seen (and still see) from Java and C#
web apps. Even though those languages have more fancy analysis than
we are proposing for ES4, their type systems still cannot rule out an
NPE statically or otherwise.
So we really do want non-nullably-typed class vars to be initialized
by the time the constructor finishes, and as Dave Herman reminded me,
the settings design goes further: it avoids UEs while the constructor
is active, by forcing non-nullably-typed vars to be set early, and
without reference to |this| or to other non-nullable vars.
More information about the Es4-discuss