No header files?

[Yigal Chripun]

On 22/10/2009 18:52, BCS wrote:
> Hello Yigal,
>
>> On 22/10/2009 00:57, BCS wrote:
>>
>>> Hello Yigal,
>>>
>>>> As you said, what is needed is a better lib format. we already have
>>>> DDL NOW which already has most of what you described above. D can
>>>> also take advantage of the LLVM framework.
>>>>
>>> Does DDL or LLVM work to generate monolithic executable that use all
>>> of D's features and do so for both Win32 and *nux?
>>>
>>> Also, can I use notepad to view either of those file types?
>>>
>> from http://llvm.org/docs/LangRef.html
>> <quote>
>> The LLVM code representation is designed to be used in three different
>> forms: as an in-memory compiler IR, as an on-disk bitcode
>> representation (suitable for fast loading by a Just-In-Time compiler),
>> and as a human readable assembly language representation. This allows
>> LLVM to provide a powerful intermediate representation for efficient
>> compiler transformations and analysis, while providing a natural means
>> to debug and visualize the transformations. The three different forms
>> of LLVM are all equivalent.
>>
>> </quote>
>
> So, if your library has LLVM code representation, then it's easier to
> get to but just as bad as reading a ASM dump from the compiler.
> I'm being more than a bit sarcastic there, but keep in mind that 99% of
> the info I'm interested in isn't in the assembly code (function names,
> argument names, types, comments) and/or would be better viewed as the
> original source.

even though it looks like ASM it is not the same. the llvm will contain 
the info (function names, argument names, types, comments) as metadata.
visual studio has a view to see all metadata in an assembly, and D IDEs 
will implement a similar properties view to show the same info.

comparing to original source is useless - commercial companies may want 
to protect their commercial secrets and provide you with only a binary 
file and the bare minimum to use that file in your projects. D needs to 
support that option. of course it would be wonderfull if everything 
would be open-source but D can't force this on everyone and if we want D 
to be mainstream it needs to support such paradigms as well.

>
>>
>> IIRC DDL wraps objects/libs with meta-data.
>>
>> while it will be easy to get a text representation with llvm (the
>> equivalence that is mentioned above) why would you want to do it
>> anyway? Automatically extracted documentation to a human format (ddoc,
>> javadoc, etc) is much more useful and more flexible - you can get a
>> printed manual or an interactive and easy to navigate html, you can
>> also get all sorts of graphs and diagrams that would ease
>> understanding of the structure of code.
>
> I'm cynical enough that I'd bet if D switches to a "smarter lib format"
> a lot of people would manage to forget the documentation.
> With the current system, the library must be shipped with, at a minimum,
> a human readable list of prototypes.
>
without proper documentation people will have no way to know how to use 
such libraries. givven that D has DDoc to automate this process I'd say 
it'll encorage developers to provide proper documentation instead of 
just saying - go read the headers/source.

>>
>> the only valid IMO use case for header files is for linking libs - the
>> compiler can handle just find binary formats for that.
>>
>
> Truth be told I don't use .di files at all because I have yet to need to
> use a codebase where I didn't have full source.
>
that doesn't reflect the needs of everyone.