[51] in java-interest
Re: Proposed Java Language Extentions
daemon@ATHENA.MIT.EDU (Jeremy Fitzhardinge)
Fri May 5 14:30:23 1995
From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
Date: Fri, 5 May 1995 15:44:14 +1000 (EST)
To: java-interest@java.Eng.Sun.COM
> (3) Allow /** ... */ comments everywhere. Accepted. We agreed that
> doc-comments will be allowed everywhere, but when used out of
> context they will generate a warning.
I'm unclear about the exact status of /** */ comments in the language.
Are they something which the compiler has to pay any attention to? Do
they appear in the resulting .class file? If not, are they just
javadoc's resposibility to use (and warn about)?
> (8) Multiple return values. Postponed. Java allows only one return
> value which is often annoying and may lead to inefficient code.
> Two alternatives were proposed. Mesa syntax (would affect both
> the method declaration and method calls, I'm not sure what the
> Mesa syntax for a method declaration with multiple return values
> is though).
>
> [a, b] <= foo(c)
>
> And a more IDL like syntax (would only affect method declarations)
>
> int foo(in int a, inout int b, out int c) {
> ...
> }
>
> The Mesa syntax was considered clearer, but the IDL syntax is
> closer to C/C++ and has the advantage that it can be used in
> expressions. The problem with the IDL syntax is the introduction
> of 3 new keywords that are already widely used as identifiers.
How about using the "return" keyword?
int foo(int a, return int b, return int c) {
I assume "inout" means the parameter is an arg passed by reference.
Since everything is passed by reference or can't be referenced, it
doesn't seem very meaningful. Anyway, you could use C++ syntax for
that:
int foo(int a, int &b, return int c) {
I presume the compiler would check that "return" parameters are
lvalues.
> (9) Trailing comma in array initializers. Accepted. You will be
> allowed to write:
>
> int x[] = {1, 2, 3, };
Hm. I hadn't realized this wasn't allowed before; I just assumed
it was because it is in C.
> (10) Nested /* */ comments. Rejected. It is currently impossible to
> comment out a method that either contains /* */ comments or has
> a documentation comment. Allowing nested comments would solve this
> problem. It was [unfortunately] rejected though on the basis that
> it is incompatible with Ansi-C.
Also hard to scan for with a regexp-based scanner.
Another extention proposal:
Using "package" as an access specifier for either a class, interface or
class/interface member. It means the object so marked is only accessable
from other classes in the same package; that is, the same as not putting
any access specifier currently.
J
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
