[m-dev.] Java naming issues

[James Goddard]

Hi Fergus,

While testing the library building for grade Java (with optimiations turned
off), I found a couple of bugs with the current setup with regard to java
naming conventions.

At the moment, if you write a program with more than one module, then try to :-
import_module one into the other, then we just output a java import statement.

eg:
x.m:    :- import_module y.
x.java: import y;

But y is already implicitly imported, since y.java is in the same directory as
x.java.  (And y.class will be in the same directory as x.class).  So this
statement is unnecessary.  Furthermore, java's `import' is only supposed to be
used to import packages so that you don't have to refer to classes by their
fully qualified name - it doesn't make sense to use it when there is no
hierarchy and in fact this causes a compile-time error.

Should I modify mlds_to_java.m to never output import statements?  Provided we
never actually need to import anything, (and we shouldn't if we always use
fully qualified names) this will work fine and solve this particular problem.

The second problem comes with sub-modules.  If I declare a sub-module `sub'
within x, I get out a file `x.sub.java` containing class `x.sub` but Java
doesn't like this.  Specifically, it decides there's a syntax error when it
gets to the dot.  Also, I noticed that we output a `package x` statement, which
doesn't make sense according to Java's naming conventions.  I see three
solutions:

1. Output class sub as an inner class of x, within x.java.
2. Produce instead `x__sub.java' containing class `x__sub` (and get rid of the
package statement)
3. Create a subdirectory `x' within both `javas' and `classs' in which to keep
class `sub'.

I don't know how easy it will be to apply any of these fixes, but number 2
seems  the simplest to me.  Let me know what you think.

Cheers,

James

Try the new improved Yahoo! Australia & NZ Search at http://www.yahoo.com.au
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------