On 11/28/2011 02:29 PM, so wrote:
> On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha <maxter@spambox.com> wrote:
>>>> How would you write libraries?
>>>> The way they do, for example, in C# - interface definitions are stored
>> in the library, no need for separate headers.
>> Are we talking about the same thing?
> Something like
> http://msdn.microsoft.com/en-us/library/ms236403(v=vs.80).aspx?
>> So it does what auto-generated .di files does, and turns it into an
> abomination, it relies on an IDE feature?
No, it has nothing to do with the IDE. The article describes a visual tool for viewing meta-data stored in a .NET binary. You don't have to use it.
Specially for you, die-hard IDE haters, this is how to use the terminal to create a mono app and library:
1. Library:
nano lib.cs
----
using System;
public class Lib
{
public static void hello() { Console.WriteLine("We don't need no header crap"); }
}
----
Compile that into a library, lib.dll:
dmcs lib.cs -target:library
2. Host:
nano app.cs
----
class App
{
public static void Main()
{
Lib.hello();
}
}
Compile and run the app:
dmcs app.cs -reference:lib.dll
./app.exe
We don't need no header crap
.
> Amazing, so now "programmer" means VisualStudio user? Probably this is
> why everyone using only C/C++ for serious library development.
>
Your information about "serious" programming is a bit outdated.
> (Please don't take it personal, this is my usual tone)
No problem.

On Mon, 28 Nov 2011 15:34:19 +0200, Max Samukha <maxter@spambox.com> wrote:
> No, it has nothing to do with the IDE. The article describes a visual tool for viewing meta-data stored in a .NET binary. You don't have to use it.
>> Specially for you, die-hard IDE haters, this is how to use the terminal to create a mono app and library:
I started to use vim/cmake "after" years of using IDEs, and one of the best if not the best VisualStudio.
> 1. Library:
>> nano lib.cs
> ----
> using System;
>> public class Lib
> {
> public static void hello() { Console.WriteLine("We don't need no header crap"); }
> }
> ----
>> Compile that into a library, lib.dll:
>> dmcs lib.cs -target:library
>> 2. Host:
>> nano app.cs
> ----
> class App
> {
> public static void Main()
> {
> Lib.hello();
> }
> }
>> Compile and run the app:
>> dmcs app.cs -reference:lib.dll
> ./app.exe
> We don't need no header crap
Now how do you know you have a "Lib", and it implements "hello", what rule enforces that?
If this is all it does, you are overlooking the most important point of header files.
> Your information about "serious" programming is a bit outdated.
What i mean by "serious" is that, if you "need" a specific language for some task what you are doing is serious.
Because you are falling back to a less known and probably more complex tools/languages, it is much harder to replace you.
I am still waiting for the next-gen game engine, next-gen video decoder/encoder, next-gen ... from those serious languages you mention.
I am not ridiculing anything, aren't these the facts?

On Mon, 28 Nov 2011 15:52:51 +0200, so <so@so.so> wrote:
> Now how do you know you have a "Lib", and it implements "hello", what rule enforces that?
> If this is all it does, you are overlooking the most important point of header files.
It was obscure.
A header enforces its contents for both library writer and library user.
If library writer needs a change in header. Both writer and the user needs to change their code.
For the second part if library writer changes anything with "implementation", that would not affect the user.
In your case it does, because there is no distinction between specification and implementation, every implementation is the new spec.

2011/11/28 Max Samukha <maxter@spambox.com>:
> On 11/28/2011 02:29 PM, so wrote:
>>>> On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha <maxter@spambox.com> wrote:
>>>>>> How would you write libraries?
>>>>>> The way they do, for example, in C# - interface definitions are stored in the library, no need for separate headers.
>>>> Are we talking about the same thing?
>> Something like
>> http://msdn.microsoft.com/en-us/library/ms236403(v=vs.80).aspx?
>>>> So it does what auto-generated .di files does, and turns it into an abomination, it relies on an IDE feature?
>> No, it has nothing to do with the IDE. The article describes a visual tool for viewing meta-data stored in a .NET binary. You don't have to use it.
>> Specially for you, die-hard IDE haters, this is how to use the terminal to create a mono app and library:
>> 1. Library:
>> nano lib.cs
> ----
> using System;
>> public class Lib
> {
> public static void hello() { Console.WriteLine("We don't need no header
> crap"); }
> }
> ----
>> Compile that into a library, lib.dll:
>> dmcs lib.cs -target:library
>> 2. Host:
>> nano app.cs
> ----
> class App
> {
> public static void Main()
> {
> Lib.hello();
> }
> }
>> Compile and run the app:
>> dmcs app.cs -reference:lib.dll
> ./app.exe
> We don't need no header crap
>
[skipped]
Probably i am mistaken that this post supports D modules (in a way, showing that header files are crap), but ...
In C# no headers are required, because it includes metadata in dynamic library.
In your example you link code to compiled library without header files.
However, this is not possible in D. Programmer have to compile his
code with library code,
which also should include all private members, which supposed to be hidden.
In attempt to eliminate "header crap" D breaks modularization.
Some comparison of C/C++/C#/D writing libraries.
C: write in separate .c file, declare exported object as opaque
structure/void*. No need to recompile program,
when library implementation changes. Program does not know
anything about private members.
Lib files are no longer required on program compilation. Code can
be separated though many files.
Negative: make changes in min 3 files (program, header, library)
when interface is changed.
C++ : one negative difference comparing with C is that private
members are known, and you need recompilation, when you change
something
related to them.
C#: as example above. No headers. Private members are not known. Just
link program upon compiling to already compiled .dll
No GC issues across libraries/program.
Actually, this is the best modularization support comparing these 4
languages.
D: currently difficulties when generating dynamic libraries in linux.
Also GC issue when calling D code from D
(from http://d-programming- language.org/dll.html). Programmer
should ship library code with program (Walter Bright showed simple
example
with function exporting. And what about a class, its methods and
private members?). Recompile everything when implementation/interface
is changed. No way to put class code in separate files. Wired
"interface file" generation which knows implementation better than its
author.
In conclusion, I find D module support the worst one.

On 11/28/2011 03:52 PM, so wrote:
> On Mon, 28 Nov 2011 15:34:19 +0200, Max Samukha <maxter@spambox.com> wrote:
>>> No, it has nothing to do with the IDE. The article describes a visual
>> tool for viewing meta-data stored in a .NET binary. You don't have to
>> use it.
>>>> Specially for you, die-hard IDE haters, this is how to use the
>> terminal to create a mono app and library:
>> I started to use vim/cmake "after" years of using IDEs, and one of the
> best if not the best VisualStudio.
>>> 1. Library:
>>>> nano lib.cs
>> ----
>> using System;
>>>> public class Lib
>> {
>> public static void hello() { Console.WriteLine("We don't need no
>> header crap"); }
>> }
>> ----
>>>> Compile that into a library, lib.dll:
>>>> dmcs lib.cs -target:library
>>>> 2. Host:
>>>> nano app.cs
>> ----
>> class App
>> {
>> public static void Main()
>> {
>> Lib.hello();
>> }
>> }
>>>> Compile and run the app:
>>>> dmcs app.cs -reference:lib.dll
>> ./app.exe
>> We don't need no header crap
>> Now how do you know you have a "Lib", and it implements "hello", what
> rule enforces that?
> If this is all it does, you are overlooking the most important point of
> header files.
Could you clarify what is the most important part? If you want to use a library, you would need to read its docs anyway. The interface files won't be of much help (D's ones will, since dmd liberally pours implementations into them). If the docs are unavailable or outdated, you can always extract the declarations from the library:
monop -a -r:lib.dll
lib
Version=0.0.0.0
Culture=neutral
PublicKeyToken=null
public class Lib {
public Lib ();
public static void hello ();
}
Creating separate interface files, taking trouble to push them around along with the library and then feeding them to the compiler are needlessly redundant steps. Or what am I missing?
>>> Your information about "serious" programming is a bit outdated.
>> What i mean by "serious" is that, if you "need" a specific language for
> some task what you are doing is serious.
> Because you are falling back to a less known and probably more complex
> tools/languages, it is much harder to replace you.
> I am still waiting for the next-gen game engine, next-gen video
> decoder/encoder, next-gen ... from those serious languages you mention.
> I am not ridiculing anything, aren't these the facts?
The fact is that apps with tight real-time requirements cannot be developed in C# for obvious reasons, and compilation models are irrelevant to the fact.
Ok, I am not a C# advocate. I hate it no less than C++ or D. It just happens that its compilation model is superior.

On 11/28/2011 04:05 PM, so wrote:
> For the second part if library writer changes anything with
> "implementation", that would not affect the user.
> In your case it does, because there is no distinction between
> specification and implementation
There is, but the specification is bundled with the implementation.

On Mon, 28 Nov 2011 18:21:03 +0200, Max Samukha <maxter@spambox.com> wrote:
> Could you clarify what is the most important part?
As i tried in the above post, header files are specs, a contract between library writer and the user.
A dll itself is not a spec, it is the implementation.
> If you want to use a library, you would need to read its docs anyway.
> The interface files won't be of much help (D's ones will, since dmd liberally pours implementations into them). If the docs are unavailable or outdated, you can always extract the declarations from the library:
>> monop -a -r:lib.dll
>> lib
> Version=0.0.0.0
> Culture=neutral
> PublicKeyToken=null
>> public class Lib {
> > public Lib ();
> > public static void hello ();
> }
>> Creating separate interface files, taking trouble to push them around along with the library and then feeding them to the compiler are needlessly redundant steps. Or what am I missing?
Well if you think that is redundant, you should neither comment nor document your code,
Because i think they are less important than what header files trying to solve, they don't even give you any guaranties.
> The fact is that apps with tight real-time requirements cannot be developed in C# for obvious reasons, and compilation models are irrelevant to the fact.
They are mostly libraries so it is more than relevant.

Separate hand written specification is rulez for human. It is best
short module description (with some useful manually written comments).
I like it more then autogenerated docs (by doxygen and so on).
Autogenerated specifications (headers and so on) are worst and ugly. But in language like java and C# it is last chance if there is no autogenerated docs and sources.