Perhaps it's too early for you to consider, but I'd highly recommend
you to get the TDPL
(http://www.amazon.com/D-Programming-Language-Andrei-Alexandrescu/dp/0321635361)
which will give you a solid introduction to the language. Otherwise,
there's always the docs at http://d-programming-language.org/.
> // Why Public
> public import java.io.File;
> public import java.io.OutputStream;
>
Any module which imports *this* module will have access to
java.io.File and java.io.OutputStream.
Lets say you have module Foo which has a function that takes a
parameter who's type is defined in module Bar. If the user imports
Foo, he will also have to import Bar. Doing a public import Bar in Foo
saves the user from having to manually import all needed modules that
Foo depends on.
> // Why No public
> import java.lang.all;
Because you don't want to pull in all modules when the user imports
*this* module. If you did a public import to java.lang.all, any code
which imports your module will import the entire java.lang package
(Note: this is assuming java.lang.all does actually do a public import
to all modules in the java.lang package. This is merely a convention
by the way, there's no rules as to what an "all" module does.).
>
> version(Tango){
> import TangoFile = tango.io.device.File;
> } else { // Phobos
> static import std.file; // why static import?? Does it impact memory?
> static import std.path;
> }
No, static imports have nothing to do with memory. It simply means you
have to fully specify 'std.file' when accessing its symbols. If
std.file has a File struct, you have to use it via
"std.file.File", and not just "File".
The module system is quite flexible, you can read about it in the docs. ;)
> public override void write( int b ){ // is override a must keyword?
> ...
> }
Read about this in the Base Class Member Function Hijacking section
here: http://d-programming-language.org/hijack.html
