On 2009-11-30 18:45:38 -0500, Ary Borenszweig <ary@esperanto.org.ar> said:

> Nick Sabalausky wrote:
>> "Ary Borenszweig" <ary@esperanto.org.ar> wrote in message news:hf03ps$lk2$1@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@michelf.com
http://michelf.com/

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

Perhaps reusing a constructor of an inherited class should be easier. Something like "alias this"? But how to refer to specific ctor overloads?

L.

On 30-11-2009 1:03, Andrei Alexandrescu wrote:
> Walter and I just discussed the matter of inheriting constructors. Our
> thought on the issue:
>
> a) If a class doesn't define any constructors and adds no fields,
> inherit constructors. Example:
>
> class MyException : Exception {}
>
> b) If a class defines at least one constructor, do not inherit
> constructors.
>
> c) If a class doesn't define any constructors but does add at least a
> non-static field -> undecided.
>
> What do you think?
>
>
> Andrei

On Fri, 04 Dec 2009 10:05:16 +0200, Lionello Lunesu wrote:

> Perhaps reusing a constructor of an inherited class should be easier. Something like "alias this"? But how to refer to specific ctor overloads?
> 
> L.
> 
> On 30-11-2009 1:03, Andrei Alexandrescu wrote:
>> Walter and I just discussed the matter of inheriting constructors. Our thought on the issue:
>>
>> a) If a class doesn't define any constructors and adds no fields, inherit constructors. Example:
>>
>> class MyException : Exception {}
>>
>> b) If a class defines at least one constructor, do not inherit constructors.
>>
>> c) If a class doesn't define any constructors but does add at least a non-static field -> undecided.
>>
>> What do you think?
>>
>>
>> Andrei


I do not want the compiler to decide this for me.

I do have cases where the constructor  has to be repeated for each generation of child classes for the values that will eventually set for some parent class.  You can object there must be something wrong with the design here.

But would it not be possible to indicate in the child class that the
constructor is the same as the parent.
	class parent {
		this(t1 everybody, t2 gets, t3 it){}
	}
	class child : parent {
		this(t1 everybody, t2 gets, t3 it)
		{
			super(everybody, gets, it);
		}
	}

Would like if the compiler could optimise the call to child.this away.

	or just shorten it indicate the constructor is the same (without
using another key word )

	Such a shortening, using a '.' or ':' would be transitive.
	class child : parent {
		//calls parent.this
		this.super(t1 everybody, t2 gets, t3 it);

	}
	class gchild : child {
		//calls parent.this
		this.super(t1 everybody, t2 gets, t3 it);
	}