On Friday, 29 March 2013 at 03:47:47 UTC, deadalnix wrote:
On Thursday, 28 March 2013 at 19:09:47 UTC, Moritz Maxeiner
wrote:
Including all isn't a solution to that problem, as this kind of
thing
will make compile time and resource explode, especially since
many things here are built out of mixins.
The problem you describe is that you consider not representing C
headers as D modules a change in the interface, correct (I
disagree, but that's another matter)? If noone interfaces with
the structure at all, e.g. by importing an all module, what you
feel is a problem won't bother anyone, as noone interacts with
the structure anymore; thus it is a solution to that problem.
Now regarding the fact that you say that solution will have the
negative side-effect of making compile time and resource
"explode": I have tested llvm-d on some of my old machines
(inluding a first-gen intel atom underclocked to about 800 Mhz)
and llvm-d compilation was never noticable slow, or used
considerable memory. But to either prove or contradict whether
this is a noticable side-effect of that solution we'd need hard
benchmarks.
Your enum choice would create a break in the documentation, as
the enum items would not match what is written in the LLVM
doxygen documentation anymore (which means I would have to
provide documentation for that difference); that also holds
true for the file structure, of course, but since you'll get
the entire C API with one import anyway ("import llvm.c.all")
there's no additional documentation needed there (it is
covered by the already existing examples).
It wont break LLVM's documentation. See for instance :
http://llvm.org/docs/doxygen/html/group__LLVMCCoreType.html
LLVMGetTypeKind is clearly documented as returning a
LLVMTypeKind, not an int.
I did not talk about functions using the enums at that point, but
about the enum definition (the enums' items):
as the enum items would not match what is written in the LLVM
doxygen documentation anymore
See here under "Enumerations":
http://llvm.org/docs/doxygen/html/group__LLVMCCoreTypes.html
The enums documentation would not match the enums anymore, as the
items' names would be different (even if it is just missing the
part about their enum's name).
If you want proper D enums (with names), though, they'll be
present in the D API - mapping to the C bindings' enum's items.
Code duplication is rarely a good idea. Especially since your
goal mentioned above is to reduce maintenance costs.
The enums in the C bindings exist in a global context, while the
enums in the D API are often bound to specific classes (as the
original C++ enums are, to which the C API enums partially map).
An alias to the C bindings' enums would not suffixe as then the
global C bindings' enums' items could still be used as arguments.
And again, my goal was/is to
"Follow the original C API code as closely as possible while
minimizing the amount of work needed to maintain the result"
Not to simply cut down on maintenence costs. Also the maintenence
cost for that is virtually nonexistent in constrast to the
header/module issue.
This goal is also followed for the D API reconstruction of the
C++ class hierarchy, so the enums that are bound to classes in
the C++ API should be bound to the classes in the D API, unless
their names already imply where they belong - as is the case with
TypeID. Literal it should e.g. become in D: "Type.TypeID.Void"
but here TypeID implies Type so I made it "TypeID.Void".
Another reason why the C bindings' enums and the D bindings'
enums will stay seperated is for compatibility with deimos-llvm,
which will be usable as a replacement for the internal C bindings
for people who e.g. want a c header -> d module translation.
