default constructors and implicit super() insertion

Brendan Eich brendan at mozilla.org
Wed Jun 27 13:36:21 PDT 2007


On Jun 26, 2007, at 6:58 PM, Brendan Eich wrote:

> The bias was against definite assignment analysis being required for
> strict mode, never mind good old standard mode, which can as Graydon
> notes detect uninitialized non-nullable properties the hard way at
> runtime, but before the ctor returns an instance whose properties
> must be well initialized.

Just to follow up on my own point: Dave Herman reminded me that we  
don't want the evil twin of the NullPointerException, to wit an  
UninitializedNonNullableTypeError (or something with a shorter  
name ;-), rising to haunt the new language. Consider:

use standard;

class C {
   private var x : Object!;
   function C(y) {
     let q = helper(y);
     x = {p: q};
   }
   private function helper() {
     /* who knows what this does! */
   }
}

The constructor function for C does not know what helper does with | 
this|. Could it reference x? If so, it would have to get that pesky  
UninitializedError, which would seem no better than its dual, the NPE  
we hope to banish from runtime once instances containing non-nullably- 
typed vars are initialized.

Settings allow us to restrict not only when non-nullably-typed  
variables are initialized, but how their initializers run --  
specifically, without access to |this|. So any helpers would have to  
be static or outer (global, package internal) functions.

This seems like a better design both for non-nullability as a usable  
feature, and for simpler, smaller, faster implementations. It's true  
that it requires dedicated syntax, but that is just a "UI" corner  
case -- not unlike graphical UI settings that you don't often need,  
but can't live without in a crunch.

/be





More information about the Es4-discuss mailing list