On 2011-05-24 15:17, Matthew Ong wrote:
Hi Andrej,
On 5/24/2011 7:13 PM, Andrej Mitrovic wrote:
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.
Understood. hmm...So, this is there to avoid the layout of java.io.all?
Because, if there is such all.d file within java.io module, it would
have public import all classes with there?
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.).
Understood.
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".
Please explain more if possible with some example code.
The reason for the static import is to avoid conflicts in std.file and
std.path. Using static imports, the compiler will force you to use fully
qualified names, i.e. "std.file.File", instead of 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
Ok. The override has something to do with function
hijack(feature/avoiding unintended behavior of import), the sound of the
name give me the idea of unintended behavior of import within D.
How about this?
// How is this being used within the context of this class? What if
there is another overloaded write signature?
alias java.io.OutputStream.OutputStream.write write;
alias java.io.OutputStream.OutputStream.close close;
http://hg.dsource.org/projects/dwt2/file/d00e8db0a568/base/src/java/io/ByteArrayInputStream.d
8 alias java.io.InputStream.InputStream.read read;
9 alias java.io.InputStream.InputStream.skip skip;
10 alias java.io.InputStream.InputStream.available available;
11 alias java.io.InputStream.InputStream.close close;
12 alias java.io.InputStream.InputStream.mark mark;
13 alias java.io.InputStream.InputStream.reset reset;
14 alias java.io.InputStream.InputStream.markSupported markSupported;
What are these for? How is the alias works with override and NOT
overloading?
http://d-programming-language.org/hijack.html
If >overloading< of foo between X and Y is desired, the following can be
done:
alias X.foo foo;
alias Y.foo foo;
Where-else here, It has to do with ByteArrayInputStream inheriting and
overriding from InputStream.
The documentation of D need to be more open and consolidated. From what
I can see, it does seem to be ad-hoc build, rather than properly
organized by design.
The reason for the aliases is this:
class A {
void foo (int i);
}
class B : A {
void foo ();
}
To be able to call A.foo(int) from B you need to add an alias to it. In
D, unlike in Java, the methods in A and B will be in two different
overload sets.
Have a look at:
http://www.digitalmars.com/d/2.0/function.html#function-inheritance
Read the second and third examples.
--
/Jacob Carlborg
