[52] in java-interest

home help back first fref pref prev next nref lref last post

No subject found in mail header

daemon@ATHENA.MIT.EDU (Steve_Kilbane)
Fri May 5 14:30:58 1995

Date: Fri, 5 May 1995 08:32:26 +0100
From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane)
To: java-interest@java.Eng.Sun.COM

> (1) Alternative notations for methods returning array. Accepted.
>     Currently a method that returns an array is declared as follows:
> 
> 	int foo()[] {
> 	    ...
> 	}
> 
>     Although this is consistent with Ansi-C it is considered
>     fairly obscure. We have agreed to also allow the notation
>     where the []'s appear after the return type. For example:
> 
> 	int[] foo() {
> 	    ...
> 	}
> 
>     Note that the old syntax will still be allowed. As a result we will
>     also allow the []'s to follow types in other declarations. For
>     example, this declares two arrays of integers:
> 
> 	int[] a, b;
> 
>     For completeness and backward compatibility it will be allowed 
>     to mix both notations (it should be discouraged though). The
>     following declares 'a' to be an array of integers and b to be
>     an array of arrays of integers.
> 
> 	int[] a, b[];

One of the things I like about Java is a move towards
safer programming constructs, i.e. the language prevents
the programmer from making some of the mistakes common
in C. The garbage collector and array bounds checking
are examples. Thus I think it's a shame that Java isn't
addressing one of C's more irritating features - it's
type declaration syntax. I frequently see

char* a,b;

which, to the beginner, implies that both a and b are
(char*). It's also not that uncommon for experienced C
writers to add the b variable to the list, and to forget
to add the *.

So for Java, I'd prefer either of:

(a) having the constructor bind to the type, rather than
to the variable, as

int[] a,b;

does.

(b) only allowing variables of the same type to be declared,
which would outlaw

int[] a, b[];

Bit of a contentious issue, but I thought I'd mention it. :-)

> (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.

Should make the syntax a little more interesting. :-) Will
doc-comments used out of context still function as doc-comments,
or will they be treated as normal /* ... */ comments?

steve

-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post