On Jun 26, 2007, at 6:32 PM, Graydon Hoare wrote: > 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.
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. Perhaps for strict mode we could require DA analysis. If so, we could get rid of settings as special syntax. But settings relieve a cost not only to implementors -- they also (idiomatic and possibly hated syntax aside) require users of non-nullable types to put initialization front and center, not possibly obscured or missed in the ctor's body's control flow. > Anyone want to chime in? I suspect a couple of the people with > opinions > are presently or shortly on vacation... Indeed. We'll hear back in a few weeks, if not sooner, from some group members now on vacation. >> BTW does anyone have any thoughts on my original questions? > > Automatic inference of the default ctor signature and default super- > call > from the superclass would be fine by me. I'm not sure what other > people > think. It'd break AS code. Peter, could you remind me how super and subclass ctor parameter lists would be related? There's no necessary relation. How would this work, other than as a convention supported by default, requiring overriding to avoid type or argument number errors? /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
