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