inheriting constructos

davidl davidl at nospam.org
Mon Nov 30 01:17:33 PST 2009


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

> On Mon, 30 Nov 2009 03:18:27 +0300, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> Denis Koroskin wrote:
>>> On Mon, 30 Nov 2009 02:20:40 +0300, bearophile  
>>> <bearophileHUGS at 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/



More information about the Digitalmars-d mailing list