Re: enhance an array's static type by a lower length-bound.
Robert Klemme <shortcutter@googlemail.com> wrote:
On 17.08.2011 17:04, Andreas Leitgeb wrote:
The point of the idea is, that array variables would be added a static
bit of information, namely a lower bound (0 by default) for the length
of an array that can legally be stored in that variable.
I believe such a change would be source-compatible, but might require
some severe changes at the bytecode/class-file-format level, to allow
to specify such a lower bound in a type signature. Such a change should
be possible in a way, that old class-files can still be used. e.g.:
get9th:(]10I)I (currently without bounds: get9th:([I)I )
Methods could overload others just for different length-bounds.
The one with the largest provably satisfyable length-bound would be
chosen among those with otherwise matching signature.
Not sure whether this would work - especially since binding of the
signature occurs at compile time while you might only learn the real
length of a parameter at runtime.
That was the point, that the resolution would still be at compile-time,
and based on the particular statically known length bound, not the actual
length.
e.g.:
void foo(int[] ia) { ... }
void foo(int[10] ia) { ... }
void foo(int[20] ia) { ... }
...
foo(new int[25]) -> third
int[5] ia = new int[15];
foo (ia ) -> first, not second!
That would be entirely consistent with
void foo (Object o) { ... }
void foo (List l) { ... }
void foo (ArrayList al) { ... }
...
foo ( new ArrayList() { ... } ) // (subclass of AL) -> 3rd.
Collection c = new Vector();
foo ( c ) -> calls first, not second.
Also there is probably a whole lot of issues with java.lang.reflect.
Hmm, the Class-instances representing arrays e.g. for a call to
Class.getMethod() likely would need to be specific for each bound.
There'd need to be a way to get a class-object for, say, int[42].
May be tricky, but doesn't seem impossible to me.
If you know of a specific difficulty here, then I beg you to speak up!
Another one could be, that ArrayIndexOutOfBoundsExceptions are
not currently perceived as a problem that could be alleviated
by static checks, anyway.
I think this is closer to the real reason why this is probably
not such a good idea.
I don't refute this. I just like to principially think it through,
anyway. Maybe until some show-stopper "that can't ever work" is
brought up.
What you propose would be useful only if the added
property of arrays would allow for *compile time* checking -
Well, that's the intention behind it - to some degree.
because Java has runtime checks already. For compile time checks to be
reasonable you would need to forbid
int[] a1 = expr;
int[10] a2 = a1;
I wrote that in my original post, already. It requires an explicit
cast in the second line, and the cast would mean that a runtime check
on the length occurs. Principially the same story as with object-type
casts.
because depending on the complexity of expr it might not be possible for
the compiler to determine the guaranteed min length of a1.
The guaranteed min length of a1 is 0 - because the brackets are empty.
I have the feeling that
people would use this as a lazy shortcut for defining a class with n
integer fields.
That would be an admittedly entirely unwanted dead giveaway, but just
like the imbalance of cost vs practical applicability, I'd like to
keep that out of the technical discussion. It would be relevant, if
it was intended as a serious proposal, but that isn't the case here.