[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. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
