Re: eerie Java-BASIC (partially OT)
BGB wrote:
Lew wrote:
BGB wrote:
the main difference would likely be the potential loss of a 1:1 mapping
between source-files and output class files.
You cannot lose what doesn't exist to start with. Source files in the
usual Java implementation (i.e., one that uses files) have a 1-to-many
relationship with classes (and therefore with class files in file-based
implementations). This applies for both nested classes and top-level
classes. (In a certain very loose sense, an inner class exists
separately for each instance of its containing class.)
fair enough.
what I meant was more like:
you have Java source file in a given path with a given base name;
it is compiled;
it results in a class file in the same path with the same base name
representing the contained class (except in cases where there may also
be additional output files).
if the language were using a different structure, then the compiler
Well, that's not actually part of the Java language. It exists only in current file-
based implementations of it like the Reference Implementation.
There is nothing in the Java Language Specification that requires that file-
based scheme, or any file-based scheme. Read the introduction of Chapter 7.
It's barely mentioned, only to say that Java bytecode can live in files or databases,
and that tools might require some conventions.
I suspect if we find a way to store bytecode in other than files or databases
that the stewards of Java wouldn't blink.
output would more often be in different paths with different names from
the source files.
That's not an aspect of other languages, either, but of their tools.
Regardless, in Java there is no requirement that file names match class
names, nor even that files be used at all.
I am not really intending to argue here about how similar or different
"namespace" and "using" are from "package" and "import" though.
There's no room for argument. They are exactly as similar and different
as they are. The degree of similarity and difference is objectively
verifiable, as the terms are publicly and transparently defined.
I took exception to your characterization of the differences between
keywords "namespace" and 'package' and between "using" (the statement,
not the directive) and 'import' as "likely minor". Definitions of
"minor" vary, but in my world, "nearly completely different" is not
minor. (To be fair, the C# "using" directive is rather similar to the
Java 'import', but the "using" statement is quite different. The "using"
statement is similar to Java's new try-with-resources.)
I was never talking about:
"using(object)" or similar.
Fair enough.
yes, this is "almost completely different" from import.
I meant solely the "using", as in:
namespace foo {
using bar;
...
}
where, functionally:
package foo;
import bar.*;
is at least vaguely similar to the above (apart from their relations to
compiler and loader behavior, ...).
True.
There is no doubt that "namespace" and "using" could be made to work on
the JVM, for a language that uses those constructs. Java might move in
the "namespace" direction itself with the proposed module semantics. As
for "using", I don't see that coming to Java soon, but maybe. It might
even be part of modules, too; I haven't read up on those yet. (I don't
see anything recent coming out of this effort.)
<http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html>
<http://openjdk.java.net/projects/modules/>
dunno really...
would have to look into it all a bit more to be more certain.
(quick skim of "modules", seems like it is dealing with an altogether
different problem).
but, there is ActionScript3 which does things like this:
package foo.bar {
import baz;
...
}
so, it is sort of like a hybrid...
The current Java ecosystem of packages, JARs, WARs and EARs
works well enough, apparently, or the modules proposal would
have shown some life in the last five or more years. They're
saying it is in the hopper for Java 8, but they used to say it'd
be in Java 7. Apparently demand hasn't been high enough to
accelerate it.
--
Lew