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/[email protected].
