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
on...@yahoo.com
Mafi
