How to break module into multiple file.

[Matthew Ong]

On 5/20/2011 4:23 AM, Nick Sabalausky wrote:
> "Matthew Ong"<ongbp at yahoo.com>  wrote in message
> news:ir3801$84b$1 at digitalmars.com...
>> On 5/14/2011 3:17 AM, Nick Sabalausky wrote:
>>> "Jason House"<jason.james.house at gmail.com>   wrote in message
>>
>>> But yea, one-class-per-file is really a Java thing (and then a few other
>> Not true entirely, the limit is one public class per file. There is no
>> actual limit for such:
>> // The file must be ClassA.java
>>
>> public class ClassA{}
>>
>> class ClassB1{}
>> class ClassB2{}
>> class ClassB3{}
>> class ClassB4{}...
>>
>>
>

> I see. But in any case, D allows multiple public classes in one file, FWIW.
Yes. I agree that the multiple public class per file is good. I can the 
uses of that when it does not come into library but in Web Page 
Rendering, Business Logic Layer and GUI Logic Layer(Java really messes 
thing up here for swing GUI.)

>
>
>>> languages kind of ape'd it.). No need to force youself into that in D.
>>
>> As for the real reason it is for:
>> That current D layout seem to limit that one file to a single developer.
>> Instead of multiple classes by multiple developers within the same module.
>>
>> Using the example:
>> HashMap&  Unit tested implemented by matthew
>> LinkedList&  Unit tested implemented by john
>> but the same module is handled by Jonathan for other classes?
>>
>
> That's what version control systems are for. As long as you're using a VCS
> that isn't terrible (ie, as long as you're not using CVS or Visual
> SourceSafe), than it's easy for multiple people to edit the same source
> file.
OK. I read somewhere else about this, I think there is same issue for 
SubVersion?
Someone suggested Hg.

But that does not work well for some security centric applications like 
where they divide up even the accountability of the developer to the 
code. How can someone proof that if multiple person changes the same 
peace of code. Like in Defence and Banking people might ask this questions.

>
>> But Nick,
>> -- ...to this: ---
>>
>> // libfoo/all.d
>> module libfoo.all;
>> public import libfoo.partA;
>> public import libfoo.partB;
>> public import libfoo.partC;
>>
>> That does the trick.
>
> Great :)
The breaking up allow me to even hide some class that I do not want. I 
think I begin to understand how D does its package/module layout.
Using the approach that you shown here, allow me to think about how to 
migrate some of the Java API I have coded.

>
>> Now my only concern is that when does D linked like C++ or dynamic
>> selective linked on import that is ONLY really used and not linked ALL
>> that is imported....Such thing does not happen in Java because linking is
>> done during runtime by Class Loader. I wonder the loader in D for DLL is
>> as intelligent.
>>
>
> AIUI, automatic DLL loading is handled by windows, not D (but I think you
> can also load DLLs manually). Also, D is usually linked statically, not
> dynamically. I know it's possible for a static linker to eliminate code
> that's not used, but I don't think OPTLINK (D's linker on windows) currently
> does it.
Now. That is a feature request to be seriously look into.


-- 
Matthew Ong
email: ongbp at yahoo.com