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

Andrei Alexandrescu:
> c) If a class doesn't define any constructors but does add at least a non-static field -> undecided.

Does 'undecided' mean 'compile-time error'?"

Bye,
bearophile

On Mon, 30 Nov 2009 02:20:40 +0300, bearophile <bearophileHUGS@lycos.com> wrote:

> Andrei Alexandrescu:
>> c) If a class doesn't define any constructors but does add at least a
>> non-static field -> undecided.
>
> Does 'undecided' mean 'compile-time error'?"
>
> Bye,
> bearophile

I think it means they are not decided whether it should inherit constructors.

Back on topic, I do think inheriting constructors is a good idea, even in presence of additional fields (why not?)

I also think constructor inheritance could be implemented without any changes to the language the following way:

this(Args...)(Args args) if (__traits(compiles, super(args)))
{
    super(args);

    // initialize additional fields, if any present
    // and/or do some post-construction logic
}

Why create new rules? :)

The trivial way could be even simplified like this:

// just a basic idea
template InheritCtors()
{
    this(Args...)(Args args) if (__traits(compiles, super(args)))
    {
        super(args);
        static assert (this.tupleof == super.typleof); // check that no additional members present
    }
}


class Foo { /* a few different ctors */ }

class Bar : Foo
{
    mixin InheritCtors(); // Voilà!
}

bearophile wrote:
> Andrei Alexandrescu:
>> c) If a class doesn't define any constructors but does add at least a non-static field -> undecided.
> 
> Does 'undecided' mean 'compile-time error'?"

We're undecided.

Andrei

Denis Koroskin wrote:
> On Mon, 30 Nov 2009 02:20:40 +0300, bearophile <bearophileHUGS@lycos.com> wrote:
> 
>> Andrei Alexandrescu:
>>> c) If a class doesn't define any constructors but does add at least a
>>> non-static field -> undecided.
>>
>> Does 'undecided' mean 'compile-time error'?"
>>
>> Bye,
>> bearophile
> 
> I think it means they are not decided whether it should inherit constructors.
> 
> Back on topic, I do think inheriting constructors is a good idea, even in presence of additional fields (why not?)
> 
> I also think constructor inheritance could be implemented without any changes to the language the following way:
> 
> this(Args...)(Args args) if (__traits(compiles, super(args)))
> {
>     super(args);
> 
>     // initialize additional fields, if any present
>     // and/or do some post-construction logic
> }
> 
> Why create new rules? :)

Alas, that doesn't work because of ref and out arguments. I actually think it's a language bug that it's impossible to implement perfect forwarding.

Andrei

On Mon, 30 Nov 2009 03:18:27 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Denis Koroskin wrote:
>> On Mon, 30 Nov 2009 02:20:40 +0300, bearophile <bearophileHUGS@lycos.com> wrote:
>>
>>> Andrei Alexandrescu:
>>>> c) If a class doesn't define any constructors but does add at least a
>>>> non-static field -> undecided.
>>>
>>> Does 'undecided' mean 'compile-time error'?"
>>>
>>> Bye,
>>> bearophile
>>  I think it means they are not decided whether it should inherit constructors.
>>  Back on topic, I do think inheriting constructors is a good idea, even in presence of additional fields (why not?)
>>  I also think constructor inheritance could be implemented without any changes to the language the following way:
>>  this(Args...)(Args args) if (__traits(compiles, super(args)))
>> {
>>     super(args);
>>      // initialize additional fields, if any present
>>     // and/or do some post-construction logic
>> }
>>  Why create new rules? :)
>
> Alas, that doesn't work because of ref and out arguments. I actually think it's a language bug that it's impossible to implement perfect forwarding.
>
> Andrei

Well, intuitively it should be implemented this way:

class Foo { /* a few different ctors */ }

class Bar : Foo
{
    alias super.this this; // the same way you do
    // "alias super.someMethod someMethod;" to add someMethod into current scope
}

Unfortunately, this conflicts with alias this feature. If we could rename constructors from "this" to "ctor", we could use it with no ambiguity:

class Bar : Foo
{
    alias super.ctor ctor;

    ctor(Other other)
    {
       // ... shoudn't conflict with existing ctors (or should it?)
    }
}

This would also help getting rid an ugly "__ctor" identifier which is used as placement new:

void[] mem = allocate!(T);

// old style
T.__ctor(mem);

// new style
T.ctor(mem);

Denis Koroskin:
> Unfortunately, this conflicts with alias this feature. If we could rename constructors from "this" to "ctor", we could use it with no ambiguity:

That's another keyword, I think.

When I read that word it reminds me this word: http://www.legrog.org/visuels/couvertures/71.jpg

Sorry, bye,
bearophile

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:heuuk9$1nfq$1@digitalmars.com...
> 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 could swear that I've recently been using a language that does exactly that (with 'c' falling in the same category as 'a'), and have been very happy with how it handles that, but I can't remember what language it was (it was probably Haxe, maybe C#...I guess it wasn't D ;) ). So yea, I'm all for it (with 'c' acting like 'a').

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 would add: "and the class does not define a class invariant".

A constructor exists to establish the class invariant (even if that invariant is implicit). For (a), the old invariant will still be satisfied.
In the case (c) there is a chance that the invariant will not be appropriate. In (c), I suggest that it is valid to inherit constructors if and only if the new class is a simple aggregate of the old class, together with the new members (which may have invariants of their own).
If there's no constructor and no invariant, then either it's a simple aggregate, or it's a bug.

在 Mon, 30 Nov 2009 09:35:17 +0800，Denis Koroskin <2korden@gmail.com> 写道:

> On Mon, 30 Nov 2009 03:18:27 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Denis Koroskin wrote:
>>> On Mon, 30 Nov 2009 02:20:40 +0300, bearophile <bearophileHUGS@lycos.com> wrote:
>>>
>>>> Andrei Alexandrescu:
>>>>> c) If a class doesn't define any constructors but does add at least a
>>>>> non-static field -> undecided.
>>>>
>>>> Does 'undecided' mean 'compile-time error'?"
>>>>
>>>> Bye,
>>>> bearophile
>>>  I think it means they are not decided whether it should inherit constructors.
>>>  Back on topic, I do think inheriting constructors is a good idea, even in presence of additional fields (why not?)
>>>  I also think constructor inheritance could be implemented without any changes to the language the following way:
>>>  this(Args...)(Args args) if (__traits(compiles, super(args)))
>>> {
>>>     super(args);
>>>      // initialize additional fields, if any present
>>>     // and/or do some post-construction logic
>>> }
>>>  Why create new rules? :)
>>
>> Alas, that doesn't work because of ref and out arguments. I actually think it's a language bug that it's impossible to implement perfect forwarding.
>>
>> Andrei
>
> Well, intuitively it should be implemented this way:
>
> class Foo { /* a few different ctors */ }
>
> class Bar : Foo
> {
>      alias super.this this; // the same way you do
>      // "alias super.someMethod someMethod;" to add someMethod into current scope
> }
>
> Unfortunately, this conflicts with alias this feature. If we could rename constructors from "this" to "ctor", we could use it with no ambiguity:
>

I think opDispatch should be able to simulate the current alias this feature. And current alias this should be something work like the example you provided.


> class Bar : Foo
> {
>      alias super.ctor ctor;
>
>      ctor(Other other)
>      {
>         // ... shoudn't conflict with existing ctors (or should it?)
>      }
> }
>
> This would also help getting rid an ugly "__ctor" identifier which is used as placement new:
>
> void[] mem = allocate!(T);
>
> // old style
> T.__ctor(mem);
>
> // new style
> T.ctor(mem);


-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/