Michel Fortin wrote:
On 2009-11-30 18:45:38 -0500, Ary Borenszweig <a...@esperanto.org.ar> said:
Nick Sabalausky wrote:
"Ary Borenszweig" <a...@esperanto.org.ar> wrote in message
news:hf03ps$lk...@digitalmars.com...
Andrei Alexandrescu wrote:
c) If a class doesn't define any constructors but does add at least
a non-static field -> undecided.
What do you think?
I think c should be a compile-time error.
Why? (Not to be contentious.)
At first I thought you might want to add fields to a subclass for
logging, or caching, stuff like that, while still wanting to inherit
the constructors. Then I checked some code for a project I wrote in
Java and always when the subclass had new fields it defined a
different constructor, and the logging fields were static. So I think
that most of the time you'd want to inherit the constructors when you
don't define new fields.
But then how do you go from "most of the time you want to inherit the
constructor" to "it should be a compile-time error"? Do you believe
people would forget to add the constructor when it's needed, leading
into hard to find bugs?
I often create subclasses in Objective-C where I just override one
method so I can hook a custom behavior somewhere, and this often
requires a new field. But most of the time the default value given to
that field at construction (null or zero) is fine so I don't bother
needlessly rewriting constructors.
The question then is: should I be forced to add a constructor when I
don't need one because you want the compiler to remind you you should
when you add a field? I'm not sure which side wins at this question. And
in this case I'd go for the most simple rules: don't bother about added
fields.
I think that unit testing is one of the most important things when
programming, so letting the compiler always inherit the constructors for
you is ok (if you don't define at least one constructor) because if you
forgot to initialize a field you'll catch the bug sooner or later in a
unit test or (hopefully not!) in runtime.