Making D Lang More easy.

[Mafi]

Am 11.05.2011 16:48, schrieb Matthew Ong:
> Hi Mafi,
>
> Thanks very much for the prompt reply. Thanks for the various links.
> BTW, are you an employee within digitalmars?
>
>
>> class C {}
>> interface I { void print(); }
>> abstract class D: C,I {}
>
>> void main() {}
>
> I need class D to be solid class doing both inherits from C but
> allow me to provide code and for interface I.
import std.stdio;

class C {
     void print() { writeln("print");}
}
interface I { void print(); void  print2();}
class D : C, I {
     void print() { super.print(); }
     void print2() { writeln("print2"); }
}

void main() {
     auto d = new D;
     d.print();
     d.print2();
}
> BTW, does it matter if the compilation process goes this way?
> The order of the code appearing in different file.

The order in which appear declarations does not matter in D. If it does, 
it's a bug. The file in which you define and the order in which you 
import does not matter. There's never function shadowing in that form. 
(functions in this module shadow imported functions and some other minor 
stuff).

>> abstract class D: C,I {}
>> class C {}
>> interface I { void print(); }
> I am aware about dmd -Ipath option. And yes, import works like
> include which means (yucks!) I believe it would use the behavior of
> import in java.
>
There are modules in D meaning that every file corresponds to exactly 
one module which builds a namespace.
When you import you just make symbols of other modules visible. They are 
not compiled in. Have to link with the module to make them available.

> I like to maintain different class/interface/function into different
> file, the dmd process seem to be too particular to compile the file
> in a specific order unlike javac all I need to make sure those other
> class/interfaces i needed are within the directory or -classpath
> options.
The order in which you compile and link does not matter in D.


> That is also why I posted the import question in item 5. Google Go
> seems to not care about this, if I am not wrong. I believe the
> compiler and linker should be smart to resolved this using some
> internal mapping.
>
> Any new programming language should frees the developer to focus
> more on their business logic than to maintain library and
> dependency.
Here you are probably right but a language can't have this with having both:
- being compiled to native machine code
- and not have a standard install mechanism, which D should avoid so it 
doesn't interfere with OS install systems (eg apt).

> Btw, any benchmark done officially comparing google go/java/D?
>
> I do run cygwin and D on a windows vista platform.
>
> Matthew
> ongbp at yahoo.com

Mafi