Centralizable configured compile-time class instantiation

[Jesse Phillips]

shd Wrote:

> Hello,
> Original goal i'd like to achieve is to completely abstract user of my
> `library` from concrete code implementations which would be set in one
> centralized place (such as config file). While it's common to do that in C++ at
> runtime, i'd like to let compiler optimize more by making this in compile-
> time.
> So, the first solution i came up is to make a 'cfg' or 'impl' template, which
> accepts interface as an argument. It would be something like configurable
> std.container : make. Inside this template, i could read and parse simple
> configuration file to find proper implementation, and return it for user.
> Unfortunately, i'm not aware of any method of instantiating any class in
> template like this.
> That's why i started to implementing other, simpler method. I assumed, that
> CMake which I'm using, will control include paths correctly and swap
> implementations on every build. What a dissapointment i met, when after
> refactoring my code in this way, user can see only interface because this is
> the first matching file module. Well, it's quite my fault because i believe it
> was mentioned in TDPL, that module = 1 file.
> 
> So, to sum up:
> My project is divided in two sections:
> * interfaces
> * implementations
> How to make in my D library possibility of configurable instantiation (lookup
> at compile time) by having only interface at client side?
> 
> Thanks,
> Mariusz Gliwiñski

I'm sorry to say that I don't exactly know what you are trying to achieve or problems you are having. I'm going to trying  and provide details on what I have gotten out of your message.

You can do compile-time configuration, this however is not a replacement to run-time configuration files.

What you are trying to do, you probably don't want to do. It sounds like you should be providing a library that can be expanded on rather than a configurable implementation. Maybe this is what you are trying to do, and it might help to think of it in this form instead.

D provides "Anti-Highjacking" measures to prevent a module from calling into code it did not know existed upon creation. This does prevent some interesting (and useful) patterns from being used, but generally it just results in unexpected, hard to track bugs.