Composing message - D Programming Language Discussion Forum

Warning: the post you are replying to is from 6 years ago (May 01, 2017).

Posting to General in reply to Andrej Mitrovic

Your name:Your email address (?):Subject:Message:

On Monday, 1 May 2017 at 20:01:37 UTC, Andrej Mitrovic wrote:
> On Monday, 1 May 2017 at 19:02:11 UTC, H. S. Teoh wrote:
>> 1) Suppose my base class has 3 ctors, and I only want my 
>> derived class to inherit 1 of them. Does this DIP allow for 
>> that?
>
> Initially when designing the DIP I haven't thought about this 
> use-case, but I've had more thought put into it recently. 
> Unfortunately it came a bit late, but I thought about an 
> alternate DIP design to this one, where instead of inheriting 
> *all* base class ctors, the user would selectively inherit 
> *specific* ctors. The alternate proposal is just a PR for now: 
> https://github.com/dlang/DIPs/pull/60 (direct link 
> https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md)
>
>> 2) If my derived class has no ctors (and the base class has a 
>> default ctor but also several other ctors), what if I want to 
>> suppress inheriting base class ctors (except the default)?  Do 
>> I need to individually list all base class ctors and attach 
>> @disable to them? How would this interact with future-proofing 
>> my derived class in case the base class changes in the future 
>> (e.g., more ctors got added)?
>
> Very good question, especially about future-proofing. This goes 
> back to my response to #1, and makes me think that in fact the 
> alternate design in https://github.com/dlang/DIPs/pull/60 is 
> probably a better idea.
>
>> 3) Is it legal to write `@disable this(int,int)` when the base 
>> class doesn't have a matching ctor?  This might happen, e.g., 
>> if the base class ctor was removed after the fact.  Or would 
>> all derived classes that disabled the original ctor have to be 
>> updated?
>
> It would have to be illegal.
>
>> 4) If my derived class has no (explicit) ctors, is there any 
>> semantic
>> difference between writing:
>>
>> 	class Derived : Base {}
>>
>> vs.:
>>
>> 	class Derived : Base { alias super.this this; }
>> ?
>
> There shouldn't be any semantic difference.
>
>> Would it be better to require the latter explicit form so that 
>> this DIP is opt-in (and also prevents breaking existing code 
>> that uses compile-time introspection)?
>
> I'm not really sure of real-world examples where this would be 
> the case, where a class designer has explicitly derived from a 
> class but failed to write any constructors *and* intends for 
> that class not to be constructible. In such a case, surely the 
> designer of the class would label the class as `abstract`.
>
>> Or would the added boilerplate (have to write that alias line 
>> for all derived classes) make this DIP less attractive? (Note 
>> that this essentially nullifies implicit ctor inheritance, 
>> which is one of main points of this DIP. But the point is that 
>> alternatives like this should be considered and argued against 
>> to make this DIP stronger.)
>
> I feel like implicit constructor inheritance where there are no 
> new additional constructors being introduced in the derived 
> class would be a safe default to have. I can't imagine a case 
> where this would cause bugs in user code. But I'm open to 
> seeing such examples, of course.
>
>> 5) How would this DIP interact with access controls? E.g., if 
>> the base class has a private ctor, will that be inherited 
>> implicitly? Or if the base class has a protected ctor, will 
>> the inherit ctor remain as protected?
>
> Not unless the two classes were part of the same module (and 
> thus had symbol visibility). However the implicitly inherited 
> constructor would also be private in the derived class as well, 
> so that should answer the second part of that question.
>
>> Will there be a way to inherit a base class protected ctor and 
>> make it public instead? (I.e., a form of forwarding, from a 
>> public derived class ctor to a protected base class ctor.)
>
> Interesting idea. That would be another point for the alternate 
> proposal in 
> https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md, which would allow code such as:
>
> class A { protected this ( int x ) { } }
> class B { public alias super.this(int) this; }
>
>> If the base class introduces new private ctors, will that 
>> cause any problems with derived classes implicitly inheriting 
>> all ctors (assuming they do inherit private ctors)?
>>
>> At what point does it cross the line of requiring explicit 
>> declaration of a forwarding ctor in the derived class?
>
> It's hard to tell whether it would cause problems, although it 
> is indeed possible to accidentally inherit a ctor even if it's 
> unwanted.
>
> I see the general sentiment, and I think the big question to be 
> asked here is: do we want a way to inherit "everything at 
> once", or have a simple syntax to selectively inherit some 
> constructors as in 
> https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md.

Syntax bikeshedding: When I learned alias this, I expected 'alias this = x' and 'alias this x' to be 100 % equivalent. But they are not equivalent.

Enable Markdown

Top | Forum index | About this forum

Forums