On 2010-11-11 15:51, Jacob Carlborg wrote:
First you have to import ITeacher in Student.d (if I'm reading this right).
No, the code works fine as is, but if I move the import of ITeacher from IStudent.d to Student.d, IStudent.d won't compile:
IStudent.d(4): Error: identifier 'ITeacher' is not defined IStudent.d(4): Error: ITeacher is used as a type
Second, D has (generally) no problems with circular references.
No, but I have! ;-) To be honest, I would have wanted D to outright outlaw circular references.
You only get problems when two modules is a part of a circular reference and both have module constructors. If you porting C++ code you will not have this problem since C++ doesn't have module constructors.
Actually, I'm more thinking whether D would be a good language for building really big systems. If the language more or less requires many modules to import each other, that's a big drawback in my opinion, since that makes a mess of the dependency graph. It also makes independent testing of individual modules a lot harder.
BTW, you generally don't separate your interface and implementation in D (you can to that if you want to hide your implementation).
I think information hiding is essential for a large-scale design to be comprehensible as a whole. Agreed, the module system in D hides a lot of implementation detail from being included in each compilation unit, but we must also consider not overloading the programmer with needless information.
But then again, maybe I just need to stop thinking in C++.
The import/module system in D is more like the one in Java than the one in C/C++.
OK, I'm more familiar with C++. But I really like the concept of importing modules instead of file inclusion.
Cheers, -- Per Å.
