On 11/28/2011 05:07 PM, Maxim Fomin wrote:
2011/11/28 Max Samukha<[email protected]>:
On 11/28/2011 02:29 PM, so wrote:
On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha<[email protected]>
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.
This is in no way related to the D module system, which is quite nicely
designed. You are describing issues with the tool chain. Those indeed
hamper modular compilation, and should be sorted out eventually. You
might want to file a bug report.
