inheriting constructos

[Michel Fortin]

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.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/