Thread overview | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 20, 2006 Java2D III | ||||
---|---|---|---|---|
| ||||
okay, the Java Parser, the Java AST Parser and very basic work on the D Emitter are done. DEmitter > A class that can take an ANTLR Java AST and produce formatted D Java code from it I guess the string, array and modifiers stuff will be tricky. anyway, first things first :the following table has to be transformed : is somebody out there who is kind enough to give me advice regarding the modifieres stuff : well translationg the table to D is also highly welcome <g> tokenNames[POST_INC]="++"; tokenNames[POST_DEC]="--"; tokenNames[UNARY_MINUS]="-"; tokenNames[UNARY_PLUS]="+"; tokenNames[STAR]="*"; tokenNames[ASSIGN]="="; tokenNames[PLUS_ASSIGN]="+="; tokenNames[MINUS_ASSIGN]="-="; tokenNames[STAR_ASSIGN]="*="; tokenNames[DIV_ASSIGN]="/="; tokenNames[MOD_ASSIGN]="%="; tokenNames[SR_ASSIGN]=">>="; tokenNames[BSR_ASSIGN]=">>>="; tokenNames[SL_ASSIGN]="<<="; tokenNames[BAND_ASSIGN]="&="; tokenNames[BXOR_ASSIGN]="^="; tokenNames[BOR_ASSIGN]="|="; tokenNames[QUESTION]="?"; tokenNames[LOR]="||"; tokenNames[LAND]="&&"; tokenNames[BOR]="|"; tokenNames[BXOR]="^"; tokenNames[BAND]="&"; tokenNames[NOT_EQUAL]="!="; tokenNames[EQUAL]="=="; tokenNames[LT]="<"; tokenNames[GT]=">"; tokenNames[LE]="<="; tokenNames[GE]=">="; tokenNames[SL]="<<"; tokenNames[SR]=">>"; tokenNames[BSR]=">>>"; tokenNames[PLUS]="+"; tokenNames[MINUS]="-"; tokenNames[DIV]="/"; tokenNames[MOD]="%"; tokenNames[INC]="++"; tokenNames[DEC]="--"; tokenNames[BNOT]="~"; tokenNames[LNOT]="!"; tokenNames[FINAL]="final"; tokenNames[ABSTRACT]="abstract"; tokenNames[LITERAL_package]="package"; tokenNames[LITERAL_import]="import"; tokenNames[LITERAL_void]="void"; tokenNames[LITERAL_boolean]="boolean"; tokenNames[LITERAL_byte]="byte"; tokenNames[LITERAL_char]="char"; tokenNames[LITERAL_short]="short"; tokenNames[LITERAL_int]="int"; tokenNames[LITERAL_float]="float"; tokenNames[LITERAL_long]="long"; tokenNames[LITERAL_double]="double"; tokenNames[LITERAL_private]="private"; tokenNames[LITERAL_public]="public"; tokenNames[LITERAL_protected]="protected"; tokenNames[LITERAL_static]="static"; tokenNames[LITERAL_transient]="transient"; tokenNames[LITERAL_native]="native"; tokenNames[LITERAL_threadsafe]="threadsafe"; tokenNames[LITERAL_synchronized]="synchronized"; tokenNames[LITERAL_volatile]="volatile"; tokenNames[LITERAL_class]="class"; tokenNames[LITERAL_extends]="extends"; tokenNames[LITERAL_interface]="interface"; tokenNames[LITERAL_implements]="implements"; tokenNames[LITERAL_throws]="throws"; tokenNames[LITERAL_if]="if"; tokenNames[LITERAL_else]="else"; tokenNames[LITERAL_for]="for"; tokenNames[LITERAL_while]="while"; tokenNames[LITERAL_do]="do"; tokenNames[LITERAL_break]="break"; tokenNames[LITERAL_continue]="continue"; tokenNames[LITERAL_return]="return"; tokenNames[LITERAL_switch]="switch"; tokenNames[LITERAL_throw]="throw"; tokenNames[LITERAL_case]="case"; tokenNames[LITERAL_default]="default"; tokenNames[LITERAL_try]="try"; tokenNames[LITERAL_finally]="finally"; tokenNames[LITERAL_catch]="catch"; tokenNames[LITERAL_instanceof]="instanceof"; tokenNames[LITERAL_this]="this"; tokenNames[LITERAL_super]="super"; tokenNames[LITERAL_true]="true"; tokenNames[LITERAL_false]="false"; tokenNames[LITERAL_null]="null"; tokenNames[LITERAL_new]="new"; thanks bjoern |
July 20, 2006 Re: Java2D III | ||||
---|---|---|---|---|
| ||||
Posted in reply to BLS | What does this table mean? tokenNames[POST_INC]="++"; tokenNames[Java symbol] = "D translation" ?? The main problem is, that the operator cannot be mapped 1o1. The plus in Java can concatenate two strings, in D the '~' is used. Same for += and ~=. So if the parser do not know the types of the + operands, a solution can be to make every + operation to a D function call. java: a += b; c = a + b; D: AddAssign( a, b ); c = Add( a, b ); And AddAssign, Add are overloaded with various types: Add( char[], ... ) Add( int, int ) Add( long, long ) ... Java: a instanceof ClassA D: ((cast(ClassA)a) !is null ) |
July 21, 2006 Re: Java2D III a better problem description | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frank Benoit | Hi Frank, I am sorry. My previous problem discription was a piece of ...., I was a bit in a hurry, so give me a second chance. How to translate the following Java class/method/variable modifieres into D. public, protected, private do the D counterparts have the same scope ?. static, final (or a combination of them) ...especially, when in use for Java classes. synchronized, volatile (the thread thing). any hint, tip, etc. is welcome.Thanks bjoern PS ---------------------------------------- I know about the problems you are talking about in your previous msg.. I think I should be able to solve them (better > some of them) because walking the AST back or doing AST lookaheads is possible. I am also able to visualize the AST, which is indeed, a great help. "Frank Benoit" <keinfarbton@nospam.xyz> schreef in bericht news:e9ovom$15sb$1@digitaldaemon.com... > What does this table mean? > > tokenNames[POST_INC]="++"; > tokenNames[Java symbol] = "D translation" > ?? > > The main problem is, that the operator cannot be mapped 1o1. > The plus in Java can concatenate two strings, in D the '~' is used. > Same for += and ~=. > So if the parser do not know the types of the + operands, a solution can > be to make every + operation to a D function call. > > java: > a += b; > c = a + b; > D: > AddAssign( a, b ); > c = Add( a, b ); > > And AddAssign, Add are overloaded with various types: > Add( char[], ... ) > Add( int, int ) > Add( long, long ) > ... > > Java: > a instanceof ClassA > D: > ((cast(ClassA)a) !is null ) > > > > > |
July 21, 2006 Re: Java2D III | ||||
---|---|---|---|---|
| ||||
Posted in reply to BLS | BLS wrote: > okay, > the Java Parser, the Java AST Parser and very basic work on the D Emitter > are done. > > DEmitter > A class that can take an ANTLR Java AST and produce formatted > D Java code from it > > I guess the string, array and modifiers stuff will be tricky. Arrays will be the trickiest - they're objects in Java, but something completely different in D (better, but totally not-compatible). While it may seem that it can be easily be solved with a template Array object, it can't for the simple reason, that a Derived[] is also a Base[] (but you can't put non-Derived object inside), and that's just not practically doable. You'd have to list all superclasses/interfaces for each array class that appears.. I can't think of a reasonable implementation that would mimic the arrays in Java, so I guess the only choice is to have a single implementation (non-templated) which keeps the element class type at runtime and checks on writes. That's bad, because the information on types of arrays is lost in source.. > anyway, first things first :the following table has to be transformed : > is somebody out there who is kind enough to give me advice regarding the > modifieres stuff : well translationg the table to D is also highly welcome > <g> > tokenNames[FINAL]="final"; becomes either final (for classes and methods) or const (for variables) > tokenNames[LITERAL_package]="package"; Ideally, you will take several classes and place them into one module; that way, their FQNs (full names) stay about the same. However, there is a problem there - you can't have both modules "foo.bar" and "foo.bar.baz" in D. But, since the packages do not form a hierarchy in Java (foo, foo.bar and foo.baz are as distinct as kuku, abc.def and qwe.dfg), you can rename them to something like foo.bar and foo_bar.baz for the above case. > tokenNames[LITERAL_import]="import"; This will be tricky; you can either import a) a normal class (java.util.HashMap), b) an inner class (java.util.Map.Entry), c) all members of a package (java.util.*), For the first two cases, you can also import d) one static member (import static java.lang.Math.PI) or e) all static members of a class (import static java.lang.Math.*) Assuming you do convert packages into modules (so a module contains all classes from a Java package), those become a) static import java.util; alias java.util.HashMap HashMap; b) static import java.util; alias java.util.Map.Entry Entry; c) private import java.util; // private now optional d) static import java.lang; alias java.lang.Math.PI PI; e) static import java.lang; alias java.lang.Math.sin sin; alias java.lang.Math.cos cos; etc. To get the last case just right, some analysis of class contents will have to be made... > tokenNames[LITERAL_private]="private"; this is still private, though it doesn't have the same effect - in Java private really means private, while in D it's module-private. > tokenNames[LITERAL_transient]="transient"; this is used for serialization only, can be dropped (and there is no equivalent in D) > tokenNames[LITERAL_native]="native"; luckily, no longer needed :) unluckily, you have to get the code for such a function from somewhere else, and it's probably C/C++ > tokenNames[LITERAL_threadsafe]="threadsafe"; never heard of this.. > tokenNames[LITERAL_synchronized]="synchronized"; when used with an expression, it's the same as in D, but can also be a modifier for functions. With non-static methods, synchronized func() { } becomes func() { synchronized(this) { } } With static methods, its synchronized(ClassName.class) in Java, I'm not sure whether something similar can be used in D (is TypeInfo an object or a struct?) > tokenNames[LITERAL_volatile]="volatile"; There are no volatile variables in D, so this is quite tricky; theoretically, you'd have to wrap each access of such a variable into a volatile statement... > tokenNames[LITERAL_throws]="throws"; These can be dropped (or even better - converted to DDoc ;) > tokenNames[LITERAL_case]="case"; > tokenNames[LITERAL_default]="default"; Note that there's an implicit "default: assert(0)" in D, but an implicit "default: break" in Java. > tokenNames[LITERAL_instanceof]="instanceof"; expr instanceof ClassName becomes (cast(ClassName)expr) No need to compare it to null, as it will be automatically done. > tokenNames[LITERAL_this]="this"; For inner classes, you can have an expressions OuterClass.this; no such thing in D.. > tokenNames[LITERAL_new]="new"; In Java, you can write "new Foo().method()", in D it must be "(new Foo).method()". Hope that helps :) xs0 |
July 21, 2006 Re: Java2D III WOW! THANKS! | ||||
---|---|---|---|---|
| ||||
Posted in reply to xs0 | Thanks, a lot of usefull information. I think I should open a dsource project, to publish the Java parser, the java tree parser, a few helper classes and the D Emitter (which is not worth its name at the moment, but using your and Franks info should enable me to make some progress) The D Emitter(in fact a slightly modified Java Emitter) is beside, quit easy to understand. The very optimistic goal is of course to have a D Emitter which is able to create perfect translations. A more realistic goal for the near future is to translate as much as possible, and to extensively comment the untranslated parts including translation suggestion. Bjoern "xs0" <xs0@xs0.com> schreef in bericht news:e9q7n9$2lu0$1@digitaldaemon.com... > BLS wrote: > > okay, > > the Java Parser, the Java AST Parser and very basic work on the D Emitter > > are done. > > > > DEmitter > A class that can take an ANTLR Java AST and produce formatted > > D Java code from it > > > > I guess the string, array and modifiers stuff will be tricky. > > Arrays will be the trickiest - they're objects in Java, but something completely different in D (better, but totally not-compatible). While it may seem that it can be easily be solved with a template Array object, it can't for the simple reason, that a Derived[] is also a Base[] (but you can't put non-Derived object inside), and that's just not practically doable. You'd have to list all superclasses/interfaces for each array class that appears.. > > I can't think of a reasonable implementation that would mimic the arrays in Java, so I guess the only choice is to have a single implementation (non-templated) which keeps the element class type at runtime and checks on writes. That's bad, because the information on types of arrays is lost in source.. > > > > anyway, first things first :the following table has to be transformed : is somebody out there who is kind enough to give me advice regarding the modifieres stuff : well translationg the table to D is also highly welcome > > <g> > > > tokenNames[FINAL]="final"; > > becomes either final (for classes and methods) or const (for variables) > > > tokenNames[LITERAL_package]="package"; > > Ideally, you will take several classes and place them into one module; that way, their FQNs (full names) stay about the same. However, there is a problem there - you can't have both modules "foo.bar" and "foo.bar.baz" in D. But, since the packages do not form a hierarchy in Java (foo, foo.bar and foo.baz are as distinct as kuku, abc.def and qwe.dfg), you can rename them to something like foo.bar and foo_bar.baz for the above case. > > > tokenNames[LITERAL_import]="import"; > > This will be tricky; you can either import > a) a normal class (java.util.HashMap), > b) an inner class (java.util.Map.Entry), > c) all members of a package (java.util.*), > > For the first two cases, you can also import > d) one static member (import static java.lang.Math.PI) or > e) all static members of a class (import static java.lang.Math.*) > > Assuming you do convert packages into modules (so a module contains all classes from a Java package), those become > > a) > static import java.util; > alias java.util.HashMap HashMap; > > b) > static import java.util; > alias java.util.Map.Entry Entry; > > c) > private import java.util; // private now optional > > d) > static import java.lang; > alias java.lang.Math.PI PI; > > e) > static import java.lang; > alias java.lang.Math.sin sin; > alias java.lang.Math.cos cos; > etc. > > To get the last case just right, some analysis of class contents will have to be made... > > > > tokenNames[LITERAL_private]="private"; > > this is still private, though it doesn't have the same effect - in Java private really means private, while in D it's module-private. > > > tokenNames[LITERAL_transient]="transient"; > > this is used for serialization only, can be dropped (and there is no > equivalent in D) > > > tokenNames[LITERAL_native]="native"; > > luckily, no longer needed :) unluckily, you have to get the code for such a function from somewhere else, and it's probably C/C++ > > > tokenNames[LITERAL_threadsafe]="threadsafe"; > > never heard of this.. > > > tokenNames[LITERAL_synchronized]="synchronized"; > > when used with an expression, it's the same as in D, but can also be a modifier for functions. With non-static methods, > > synchronized func() > { > } > > becomes > > func() > { > synchronized(this) { > } > } > > With static methods, its synchronized(ClassName.class) in Java, I'm not > sure whether something similar can be used in D (is TypeInfo an object > or a struct?) > > > tokenNames[LITERAL_volatile]="volatile"; > > There are no volatile variables in D, so this is quite tricky; theoretically, you'd have to wrap each access of such a variable into a volatile statement... > > > tokenNames[LITERAL_throws]="throws"; > > These can be dropped (or even better - converted to DDoc ;) > > > tokenNames[LITERAL_case]="case"; > > tokenNames[LITERAL_default]="default"; > > Note that there's an implicit "default: assert(0)" in D, but an implicit > "default: break" in Java. > > > tokenNames[LITERAL_instanceof]="instanceof"; > > expr instanceof ClassName > becomes > (cast(ClassName)expr) > > No need to compare it to null, as it will be automatically done. > > > tokenNames[LITERAL_this]="this"; > > For inner classes, you can have an expressions OuterClass.this; no such thing in D.. > > > tokenNames[LITERAL_new]="new"; > > In Java, you can write "new Foo().method()", in D it must be "(new > Foo).method()". > > Hope that helps :) > > > xs0 |
July 21, 2006 Re: Java2D III | ||||
---|---|---|---|---|
| ||||
Posted in reply to BLS | BLS wrote:
Uh, these names are tricky.
When I saw "Java2D" my first thought was that is has something to deal with 2D
graphics in Java <g>.
--
|
July 21, 2006 Re: Java2D III | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Khropov | good point, you are right, I bettter named it Antlr treewalker based Java to D Translator. ?! Bjoern "Andrei Khropov" <andkhropov@nospam_mtu-net.ru> schreef in bericht news:e9qf6c$h5$1@digitaldaemon.com... > BLS wrote: > > Uh, these names are tricky. > When I saw "Java2D" my first thought was that is has something to deal with 2D > graphics in Java <g>. > > -- > |
July 21, 2006 Re: Java2D III | ||||
---|---|---|---|---|
| ||||
Posted in reply to BLS | BLS wrote: > good point, you are right, I bettter named it Antlr treewalker based Java to > D Translator. ?! > Bjoern > Nothing against it, actually. It's the most natural name for this kind of stuff. Just my chatter. -- |
July 23, 2006 Re: Java2D III | ||||
---|---|---|---|---|
| ||||
Posted in reply to BLS | Is this project online accessible? |
July 23, 2006 Re: Java2D III | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frank Benoit | I need an other week. The current parser, treeparser ....are based on Java 1.3. But I want the Java 5 thing on dsolurce.org (allready contacted Brad) Bjoern "Frank Benoit" <keinfarbton@nospam.xyz> schreef in bericht news:e9vu3v$1anc$1@digitaldaemon.com... > Is this project online accessible? |
Copyright © 1999-2021 by the D Language Foundation