Why the compiler dosen't enforce correct module declarations?
Bruno Medeiros
brunodomedeiros+spam at com.gmail
Fri May 18 13:25:07 PDT 2007
Daniel Keep wrote:
>
> Ary Manzana wrote:
>> Manfred Nowak escribió:
>>> Ary Manzana wrote
>>>
>>>> Why use an alternative of the built-in version system?
>>> The version system is not equivalent to the module naming system.
>> Ok. My point is that it is totaly unnecessary to have the module
>> declaration say something different than it's location relative to the
>> include source path. This is like things work in Java, for example: you
>> get an error if the package declaration and the filesystem dosen't
>> match. Why not apply the same in D?
>
> I plan to use this while DDL is out of commission.
>
> For instance: I have a class engine.gx.camera.Camera, which is just the
> interface declaration (no actual contents). I then have two different
> implementations: one for GL and one for D3D; they both need to have the
> same module name, but they exist in totally different places on the
> physical filesystem.
>
> And don't say "just use version()s" since I really don't want to have to
> go around putting in version flags in every place this switch happens.
> I just want to do it once at compile time and be done with it.
>
Let me see if I got this correct, because I also do not understand how
this could not be done just as good with versioning. You said you don't
want to put "version flags in every place this switch happens". Did you
mean every place that uses/imports the Camera module?
Why not just have the Camera module change implementations according to
the version (like Chris mentioned) ? Something like:
---- engine/gx/camera/Camera.d ----
module engine.gx.camera.Camera
version(OGL) {
// OGL implementation
} else
version(D3D) {
// D3D implementation
}
---- ----
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
More information about the Digitalmars-d-learn
mailing list