"BCS" wrote
> Reply to Bruno,
>
>> I don't see how this could be dangerous in any way whatsoever, if the
>> ctor inheritance rules followed the same rules as method inheritance
>> rules:
>> * if you don't override or overload any ctor in the overload set, then
>> the whole overload set is available in the child class.
>> * if you do override or overload any ctor, well... follow the same
>> rules
>> as overriding/overloading a method.
>
>
> There needs to be an easy way to forbid one, several or all base constructors.

If you want to forbid all constructors, make a private constructor in the derived class.  Due to the scope resolution rules of D, only the most derived class' counts, unless you alias the parent's.

If you want to forbid one, then you have to forbid it the same way you do normal methods, implement all the ones you don't want to forbid.

Yes, this is a pain, but it is consistent.  If Walter wants to add a way to selectively alias in base methods, then use that way, but it needs to be consistent.

> And while were at it, it would be nice to add an auto constructor that is added to all constrictors (kind of like member variable initialization in c#)

It would be nice to be able to do this with runtime constructs, instead of being limited to compile-time ones.

-Steve

Reply to Steven,

> "BCS" wrote
> 
>> Reply to Bruno,
>> 
>>> I don't see how this could be dangerous in any way whatsoever, if
>>> the
>>> ctor inheritance rules followed the same rules as method inheritance
>>> rules:
>>> * if you don't override or overload any ctor in the overload set,
>>> then
>>> the whole overload set is available in the child class.
>>> * if you do override or overload any ctor, well... follow the same
>>> rules
>>> as overriding/overloading a method.
>> There needs to be an easy way to forbid one, several or all base
>> constructors.
>> 
> If you want to forbid all constructors, make a private constructor in
> the derived class.  Due to the scope resolution rules of D, only the
> most derived class' counts, unless you alias the parent's.
> 

yup

> If you want to forbid one, then you have to forbid it the same way you
> do normal methods, implement all the ones you don't want to forbid.
> 

one option would be:

private this(/* the signiture *){assert(false);} // forbid this
alias this this; // get everything else


>> And while were at it, it would be nice to add an auto constructor
>> that is added to all constrictors (kind of like member variable
>> initialization in c#)
>> 
> It would be nice to be able to do this with runtime constructs,
> instead of being limited to compile-time ones.
> 

I'm not following...

> -Steve
> 

"BCS" <ao@pathlink.com> wrote in message news:55391cb330b528cacf3c1a094fc2@news.digitalmars.com...
> Reply to Steven,
>
>> "BCS" wrote
>>
>>> Reply to Bruno,
>>>
>>>> I don't see how this could be dangerous in any way whatsoever, if
>>>> the
>>>> ctor inheritance rules followed the same rules as method inheritance
>>>> rules:
>>>> * if you don't override or overload any ctor in the overload set,
>>>> then
>>>> the whole overload set is available in the child class.
>>>> * if you do override or overload any ctor, well... follow the same
>>>> rules
>>>> as overriding/overloading a method.
>>> There needs to be an easy way to forbid one, several or all base constructors.
>>>
>> If you want to forbid all constructors, make a private constructor in the derived class.  Due to the scope resolution rules of D, only the most derived class' counts, unless you alias the parent's.
>>
>
> yup
>
>> If you want to forbid one, then you have to forbid it the same way you do normal methods, implement all the ones you don't want to forbid.
>>
>
> one option would be:
>
> private this(/* the signiture *){assert(false);} // forbid this
> alias this this; // get everything else

Good, I think this would work with the current rules of overloading.

>
>>> And while were at it, it would be nice to add an auto constructor that is added to all constrictors (kind of like member variable initialization in c#)
>>>
>> It would be nice to be able to do this with runtime constructs, instead of being limited to compile-time ones.
>>
>
> I'm not following...

i.e. you can already do this today:

class X
{
   int blah = 5;
}

But it has to be a compile-time constant.

It would be nice if you could use a runtime evaluated value.

-Steve

Frank Benoit wrote:
> Anonymous classes should pass through super ctors, if no ctor is given.
> 
> class C {
>    this( int i ){ .... }
>    abstract void run();
>    // ...
> }
> 
> auto c = new class(3) C {
>    this( int a ){ super(a); } //<-- this line should not be necessary.
>    void run(){}
> };

I'd argue that ctors should always be inherited if no ctor is defined, much like the regular function lookup rules for classes.  In fact, I posted a proposal regarding this maybe a year ago, but I'm too lazy to go looking for it now.


Sean

Bruno Medeiros wrote:
> Jarrett Billingsley wrote:
>> "Frank Benoit" <keinfarbton@googlemail.com> wrote in message news:g83v3k$n2u$1@digitalmars.com...
>>> Anonymous classes should pass through super ctors, if no ctor is given.
>>>
>>> class C {
>>>    this( int i ){ .... }
>>>    abstract void run();
>>>    // ...
>>> }
>>>
>>> auto c = new class(3) C {
>>>    this( int a ){ super(a); } //<-- this line should not be necessary.
>>>    void run(){}
>>> };
>>
>> All classes should pass through super ctors.  :|

Okay... I decided to dig up the proposal after all:

http://www.digitalmars.com/d/archives/digitalmars/D/Inheriting_constructors_54088.html


Sean

Reply to Steven,

>>>> And while were at it, it would be nice to add an auto constructor
>>>> that is added to all constrictors (kind of like member variable
>>>> initialization in c#)
>>>> 
>>> It would be nice to be able to do this with runtime constructs,
>>> instead of being limited to compile-time ones.
>>> 
>> I'm not following...
>> 
> i.e. you can already do this today:
> 
> class X
> {
> int blah = 5;
> }
> But it has to be a compile-time constant.
> 
> It would be nice if you could use a runtime evaluated value.
> 
> -Steve
> 

Ah, now I'm reading you correctly. That's exactly what I'm asking for. :)

On Mon, 18 Aug 2008 23:13:42 +0400, Sean Kelly <sean@invisibleduck.org> wrote:

> Bruno Medeiros wrote:
>> Jarrett Billingsley wrote:
>>> "Frank Benoit" <keinfarbton@googlemail.com> wrote in message news:g83v3k$n2u$1@digitalmars.com...
>>>> Anonymous classes should pass through super ctors, if no ctor is given.
>>>>
>>>> class C {
>>>>    this( int i ){ .... }
>>>>    abstract void run();
>>>>    // ...
>>>> }
>>>>
>>>> auto c = new class(3) C {
>>>>    this( int a ){ super(a); } //<-- this line should not be necessary.
>>>>    void run(){}
>>>> };
>>>
>>> All classes should pass through super ctors.  :|
>
> Okay... I decided to dig up the proposal after all:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/Inheriting_constructors_54088.html
>
>
> Sean

FWIW, C++0x has this feature and we still don't :p

http://en.wikipedia.org/wiki/C++0x#Object_construction_improvement