2011/7/13 Kagamin <s...@here.lot>: > Hmm... If you have > wrappers/gl/guiImpl/... > and > wrappers/what/guiImpl/... > and conditionally add them to includes > for example > with -I wrappers/gl you should be able to import guiImpl; and use > guiImpl.Window. If it's -I wrappers/what, guiImpl.Window is still > guiImpl.Window.
Yeah, that might work. I tend to see everywhere very strange problems (for other people). Like I think of including interface file from user-app, and then give him only this interface compliant instance. And if he wants to use some implementation-depended functionalities he should clearly instantiate IObjectSpecialized or import specialized.path.to.package; By doing it in way you are talking about (which is kind of less perfectionist version of method mentioned by me in first post, although *it works*), user is able to import path.to.package; then instantiate object by standard instantiation, and accidentally use implementation-dependant method. Then, he commits and someone else wants to compile end-app with different set of implementation libraries. Program won't compile because someone used method which isn't specified in portable interface. In the same time, program is assumed to work so, because it's not clear that person who wrote this call is acting unportable (so we're relying on documentation rather than no-can-do method). So it's a fail of my 'framework', which claims to let use x, y and z libraries interchangeably by only changing cmake definition, while the build breaks. Author of framework didn't gave programmer, clear feedback that he is acting unportable. I hope i didn't bored you too much with my imagination because there is something more i don't like. Directory hierarchy :) It's not D-related though. Soo, the only solutions we came up is doing it out of language (by -I impl/library/path), or messing with import/aliases in interfaces which isn't nice. Although first solution isn't as good as i hoped for, it works... which is a good start, so i'll probably do it this way :)
