The Final(ize) Challenge

[Jarrett Billingsley]

On Mon, May 18, 2009 at 12:12 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Ok, now with the advent (or rediscovery) of allMembers which I had no idea
> existed, we're ready to start some serious butt-kick reflection facilities.
>
> For starters, I'd like to present you with the following challenge. Given
> any class C, e.g.:
>
> class C
> {
>    void foo(int) { ... }
>    int bar(string) { ... }
> }
>
> define a template class Finalize(T) such that Finalize!(C) is the same as
> the following hand-written class:
>
> final class FinalizeC : C
> {
>    final void foo(int a) { return super.foo(a); }
>    final int bar(string a) { return super.bar(a); }
> }
>
> Finalize is cool when you need some functionality from an exact class and
> you don't want to pay indirect calls throughout. All calls through
> Finalize!(C)'s methods will resolve to static calls.

There are two challenging aspects that I'm running into.

The first is a more general statement about trying to generate
functions with D's metaprogramming.  It is a huge pain in the ass to
actually create a function with a given name, because the only way
that I know this can be done is with a string mixin.  As soon as we
venture into that territory, we have to consider things like how to
convert a parameter type tuple into a string, and whether or not the
.stringof a type will be correctly qualified (I've run into problems
with this before, where some code in a library is not able to mix in a
string because it doesn't import the same modules that the calling
code does, and then you just get undefined identifier errors).  For
the love of all that is holy, can we PLEASE get something like
__ident("blah")?  This would be so much easier and would probably
drastically reduce my use of string mixins in general.

The second is worse.  __ctor (if it exists) is not virtual, so it's
not possible to get a list of overloads of it with __traits.  One of
two things has to change: either __traits needs a way to get overloads
of nonvirtual functions (that seems like an incredible oversight!), or
as Sean and others have proposed numerous times, derived classes
should inherit ctors.  This would eliminate the need to write
forwarding constructors in the Finalize class altogether.