www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - New syntax within DWT / 2.

reply Matthew Ong <ongbp yahoo.com> writes:
Hi D Experts,

The reasons that I am asking these questions is to learn how to port a 
Java Library into D. The clear

I am new to D, Just less than 2 weeks. But experience in Java.

 From
http://www.dsource.org/projects/dwt/wiki/Contributors
http://www.dsource.org/projects/dwt

I have some questions about

FileOutputStream.d
-------------------------------------
module java.io.FileOutputStream;

// Why Public
public import java.io.File;
public import java.io.OutputStream;

// Why No public
import java.lang.all;

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;
}

public class FileOutputStream : java.io.OutputStream.OutputStream {

     // 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;
...
      public override void write( int b ){ // is override a must keyword?
        ...
      }

}

ByteArrayInputStream.d there is also a bunch of alias defined but not used.


Thanks very much.
-- 
Matthew Ong
email: ongbp yahoo.com
May 24 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Matthew Ong:


       public override void write( int b ){ // is override a must keyword?


Currently the -w compiler switch forces you to use it. But its usage will
become obligatory.

Bye,
bearophile
May 24 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
May 24 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
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/By
eArrayInputStream.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 yahoo.com
May 24 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
May 24 2011
parent Matthew Ong <ongbp yahoo.com> writes:
On 5/24/2011 10:01 PM, Jacob Carlborg wrote:


 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.



the methods in A and B will be in two different overload sets.


Thanks, I will look into it.
I think when it comes to memory only java class can be port over to D 
easier... Not too sure about the other like file/network, NIO and others.

I suppose I need to dig into the dsource site to see if there is any 
similar replacement for java's library X.

-- 
Matthew Ong
email: ongbp yahoo.com
May 24 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/24/11, Matthew Ong <ongbp yahoo.com> wrote:

 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.


What do you mean "something to do with function hijacking" and "gave
me the idea". Why not read the page in full to understand what it's
all about? You complain about disorganized documentation and yet you
don't even read the full page in the first place.

It's not an unintended behavior of D, it's a fix for a problem that
could be common in C++.
May 24 2011
parent reply Matthew Ong <ongbp yahoo.com> writes:
On 5/24/2011 10:13 PM, Andrej Mitrovic wrote:

 It's not an unintended behavior of D, it's a fix for a problem that
 could be common in C++.


Thanks very much for any code shown.

Thanks for the clarification.
I was not aware of this URL.
http://d-programming-language.org/
I am aware of this URL.
http://www.digitalmars.com/d/2.0/hijack.html
...
and everything is hunky-dory. As before, things go on, AAA Corporation 
(who cannot know about B) extends A's functionality a bit by adding 
foo(int):
...
Now, consider if we're using Java-style overloading rules, where base 
class member functions overload right alongside derived class functions. 
Now, our application call:
...
b.foo(1);   // calls A.foo(int), AAAEEEEEIIIII!!!

Please let me know if that is not mis-leading way presenting if that is 
an intended feature.

Please remind yourself, if someone is new from Java and Java has no such 
problem because the virtual method invocation has works securely and 
stable for many many years in banks and other places. The problem that 
document shown:

As software becomes more complex, we become more reliant on module 
interfaces. (Java has absolutely no ambiguous and unstable confusion.)

So... Naturally I assume D is superior in desgin and does not has this 
issue.

-- 
Matthew Ong
email: ongbp yahoo.com
May 24 2011
parent David Nadlinger <see klickverbot.at> writes:
On 5/24/11 5:36 PM, Matthew Ong wrote:

 Please let me know if that is not mis-leading way presenting if that is
 an intended feature.


You might have missed the »Now, consider if we're using Java-style 
overloading rules« part.

David
May 24 2011