inheriting constructos

[Ary Borenszweig]

Michel Fortin wrote:
> On 2009-11-30 18:45:38 -0500, Ary Borenszweig <ary at esperanto.org.ar> said:
> 
>> Nick Sabalausky wrote:
>>> "Ary Borenszweig" <ary at esperanto.org.ar> wrote in message 
>>> news:hf03ps$lk2$1 at 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.