Inheritance of mixin

Basile B. via Digitalmars-d digitalmars-d at puremagic.com
Mon May 2 10:37:14 PDT 2016


On Monday, 2 May 2016 at 16:41:01 UTC, tsbockman wrote:
> On Saturday, 30 April 2016 at 01:06:18 UTC, Andrew Benton wrote:
>> Additionally, any libraries that provide a base class with a 
>> mixin require inheritors to know about that mixin and provide 
>> it in their own code.  It certainly isn't going to happen in 
>> every case, but if the needed functionality is provided by 
>> mixins, then users of the library could have problems.
>
> I spent a while trying to figure out how to automatically 
> verify that a mixin required by a class hierarchy is included 
> in all derived classes, and failed to come up with a general 
> purpose solution. (I found a partial solution involving a `this 
> T` templatized constructor, but it had a lot of problems.) So, 
> I agree now that this is a problem worth solving.
>
> It could be fixed by extending template mixins as you and 
> others have proposed.
>
> Another possible solution would be to fix `this T` template 
> functions to be virtual, and automatically generate an override 
> for each derived class. This would directly solve the most 
> common use case, and also provide an (awkward) way to 
> automatically verify mixin inclusion in derived classes for 
> more complex scenarios.

templatized functions in classes will never be virtual and 
there's a technical reason explained here:

https://issues.dlang.org/show_bug.cgi?id=1657#c1

(TL;DR: it's problematic to generate the vtbl)

In some cases, remixing a template in each sub classes works (for 
example here https://github.com/Mihail-K/witchcraft#caveats), in 
some cases a template with a template this parameter works but 
**here** it's true that among the workarounds,  none is conform 
with the OOP principles as noted in this answer: 
https://forum.dlang.org/post/pacfkkgazpqaodsbqoss@forum.dlang.org.






More information about the Digitalmars-d mailing list