New syntax within DWT / 2.

[Jacob Carlborg]

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