Centralizable configured compile-time class instantiation

shd alienballance at gmail.com
Tue Jul 12 06:33:17 PDT 2011


Firstly, thanks for response.
2011/7/11 Jesse Phillips <jessekphillips+D at gmail.com>:
> 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.

Hopefully i'll clarify it more.

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

I'm aware, and that's not my goal - let me clarify difference between
my run-time and compile-time configs.
Run-time configuration for my project might be delegated to optional
`util.cfg` package which is able to read let's say XML file that will
store things like resolution or something.

While i'm trying to make my potentially very big project possible to
make in reasonable time, i'm pretty focused on code-reusing and making
use of third-party libraries. Because external code quality might
change, my preferences might change, and APIs are not what i'd love to
work with i'd like to try pay price of composing D object interfaces i
like, and implement them with wrappers that are connecting with
external code.

So, back on to my previous example of runtime `util.cfg`, it might use
filesystem/http reader and xml/cvs formatter from package `io` (this
is gonna be run-time configuration) BUT besides of that i might like
to change xml phobos wrapper (actually this example is not the best)
with rapidxml or whatever and *this* is gonna be compile-time config.
So, config has to be configured and it is going to be configured
statically.

Ps. Don't get me wrong, i'm not in love with wrapping standard
library, but there are other classes which i'm going to use which have
no interface in phobos. This was just an example.

> 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.

Well, my end-goal is to provide complete application. Because i
embrace code reusability, i love specialized libraries and when i'll
need to implement something specialized, then share it - i'd love to
do that. I'm afraid it's more like framework than library, but i don't
like frameworks because they force you to use everything. What i'd
like to achieve is to let someone use only parts of my code for
plugging it into his application, lessen dependencies as much as i
can, while remain type-safe.

Actually, project structure looks like that:
* project/
  * bin/
  * work/
  * docs/
  * iface/
    * ae
    * ge
    * pe
    (...)
  * impl/
    * glfw
      * ge.window
      * io.hid.keyboard
      * io.hid.mouse
      (you can add other window toolkits, or just separate OpenGL
context creation code and user-input handling from different
libraries)
      * h3d
        * ge.renderer
        (...)
      (you can add any other renderers or parts of game engines if
they let you to do that)
    * project_name
      * <package.interfaces implemented by me>
  * pe
    * bullet
    * ode
    * newton
(code is opensource and publicly accessible but excuse me i don't
quote anything because it's currently ugly and unprofessional so i'm
not proud of it yet, although i figured it out it's best way to do my
way, it just needs time and work to be proud)

So, i could easily change libraries, someone might use parts of my
code by implementing bounding interfaces and as side effect i could
easily benchmark how different implementations act in my project (like
with C++ PAL).

So, if i'll handle task of abstracting all this out, and get
reasonable performance that's the other topic, but i believe it's
worth a try. All i need is to have a tool that lets me choose
implementation at compile time without interface file modification.
Any clues?

> 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.

Any anti-anti-hijacking ideas? :)


More information about the Digitalmars-d-learn mailing list