New syntax within DWT / 2.

Matthew Ong ongbp at yahoo.com
Tue May 24 06:17:03 PDT 2011


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 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.


-- 
Matthew Ong
email: ongbp at yahoo.com



More information about the Digitalmars-d-learn mailing list