default constructors and implicit super() insertion

Peter Hall peter.hall at memorphic.com
Tue Jun 26 17:43:11 PDT 2007


Seems like we are talking about adding another new syntax to the
language, that will be alien to existing JS and AS developers, not
familiar with C++.

This syntax doesn't seem to add anything either. It's equivalent to
enforcing that you initialize the properties in the constructor (as
opposed to doing it in other functions that could be invoked by the
constructor). But you could enforce that same restriction without the
new syntax. I don't know much about compilers, but is it really too
expensive to check that each non-nullable property has been assigned
with a value inside the constructor body?

If you make it an error to not initialize a non-nullable property
inside the constructor body, you still leave it open to widen the
support in future editions, to permit the initializations to be in
other methods invoked by the constructor. Adopting the new syntax
would still leave this door open, but would leave redundant deprecated
syntax if you walked through it...
Having said that, there are many imaginable scenarios where the
variables are guaranteed to be initialized, but where that fact cannot
be verified at compile-time. So would it even ever be worth the
effort?


BTW does anyone have any thoughts on my original questions?

Peter


On 6/26/07, Brendan Eich <brendan at mozilla.org> wrote:
> On Jun 26, 2007, at 4:43 PM, Sho Kuwamoto wrote:
>
> > Just curious...
> >
> > In modern compilers, can't the compiler issue an error if the
> > non-nullable member was (a) not initialized in the constructor, or (b)
> > used before it was set?
>
> See the bit I wrote about "definite assignment ... analysis". Indeed
> modern compilers can do many analyses, but this is JavaScript. It has
> to be easy to implement on cell phones. It cannot spend a lot of
> time, even ignoring device-imposed code size constraints, in
> compiling downloaded code.
>
> > I've always hated the C++-style member initialization syntax and it
> > seems like a shame to add it if it could be avoided.
>
> C++-style member initialization is being avoided. That is, you don't
> see 'C(ax, ay) : x(ax), y(ay) {}' in the constructor. It's true that
> we are using : after the parameter list of the constructor function,
> but that's unambiguous (because you can't write a return type
> annotation for a constructor).
>
> So, what do you mean, if not the : as the punctuator that introduces
> the settings? And why the hate? This corner case with one character
> in common with C++ syntax does not make the whole case "C++-style
> member initialization".
>
> > Shouldn't it also
> > be a goal to make sure that ES4 is less baroque and easier to learn
> > than
> > C++?
>
> Remember that these "settings" are required only if you use non-
> nullable types for class variables that must be initialized.
>
> Asking a question that smuggles your (unjustified) conclusion that
> this particular corner case is "baroque" is no fair. Let's define
> baroque carefully, without emotion ("hate") and whipping-devils (C++).
>
> /be
>



More information about the Es4-discuss mailing list