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

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

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

here: http://d-programming-language.org/hijack.html

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.

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

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

here: http://d-programming-language.org/hijack.html

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.

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 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
prev sibling parent 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