[50] in java-interest
Re: Proposed Java Language Extentions
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Fri May 5 14:30:23 1995
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
Date: Thu, 4 May 1995 23:09:39 -0800 (PDT)
To: java-interest@java.Eng.Sun.COM
HI Jeremy,
As usual, thanks for your input. It has been very useful...
> > (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)?
In the current compiler /** */ comments are syntaxtically significant
and can occur only before a declaration. This has been changed now so
that they are allowed anywhere. Our compiler will emit a warning if
they occur out of place though.
> > (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.
The cool thing is that they would NOT be treated as "reference" values.
Instead the function would return multiple values which are assigned to
the out parameters on return. This means that if the method throws an
exception, the out parameters are guaranteed not to have changed!
I like your suggestion of using "return" instead of "out". I don't like
the "&" syntax because that suggest the same semantics as C/C++.
> > (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.
But not in Ansi-C though!
> > (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.
But incredible useful.
> 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.
I'll suggest that at the next opportunity.
Have fun,
Arthur van Hoff (avh@eng.sun.com)
http://java.sun.com/people/avh/
Sun Microsystems Inc, M/S UPAL02-301,
100 Hamilton Avenue, Palo Alto CA 94301, USA
Tel: +1 415 473 7242, Fax: +1 415 473 7104
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
