Automatic method overriding in sub-classes

[bitwise via Digitalmars-d]

On Wednesday, 28 October 2015 at 20:04:44 UTC, Shammah Chancellor 
wrote:
> On Monday, 26 October 2015 at 23:25:49 UTC, Tofu Ninja wrote:
>
>> So we have TemplateThisParameters methods which are cool but 
>> have some drawbacks.
>> They are templates so they are implicitly non-virtual and are 
>> called based on the type of the reference.
>> It would be very nice to be able to auto generate method 
>> overrides based on the this type with out having to drop a 
>> mixin in every sub class.
>> This would be very useful for CT-reflection.
>> I will call this new feature auto override methods for the 
>> rest of this post.
>
> This kind of magic is detrimental to being able to reason about 
> the code you are writing.  If libraries do this for example, 
> there's too much spooky action-at-a-distance occurring.  Having 
> explicit mixins is the appropriate way to handle this.

There is nothing spooky going on here. The declaration would be 
clearly annotated with auto override, or whatever keyword was 
chosen. If you were inheriting from a class, and didn't like its 
auto overrides, you could manually override the functions in your 
own class to stop it.

There are several discussion on these boards about using 
druntime's RTInfo(T) achieve similar goals to what(I think) we're 
trying to do here. This feature we're talking about nicely dodges 
the issues presented by RTInfo(T), because it's effects are 
localized to a single class hierarchy, instead of trying to 
affect all classes universally. I'm thinking there may be a 
better solution somewhere in between though.

Having the compiler turn something with template parameters into 
a virtual function is a bit odd, and I don't think it will be 
obvious to everyone. I think the following would suit my needs, 
and may be a better solution:

class Base {
     static this(this This)() { }
}

The compiler would instantiate that static constructor for every 
sub class. From there, any other relevant templates could be 
instantiated, and at runtime, this static ctor could stash any 
relevant information in a collection under the key 
'typeid(This)'. Finally, 'Base' could implement a function that 
looks up the class's info by typeid(this).

I believe this solution is a great deal simpler, and less 
invasive.

     Bit