On 5/20/2011 4:23 AM, Nick Sabalausky wrote:
"Matthew Ong"<on...@yahoo.com> wrote in message
news:ir3801$84b$1...@digitalmars.com...
On 5/14/2011 3:17 AM, Nick Sabalausky wrote:
"Jason House"<jason.james.ho...@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: on...@yahoo.com
