Re: enhance an array's static type by a lower length-bound.
On 18.08.2011 23:44, Andreas Leitgeb wrote:
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!
How likely is it that you want to have vastly different implementations
of foo() with different array lenghts?
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!
As far as I can see you would need a Class instance for every
combination of base type and min length. Plus you would need to ensure
that type compatibility check methods return the appropriate boolean
values.
If you try to make them inherit (i.e. int[4] "is a" int[3]) things get
really crazy because int[4] is also an int[2] and int[1] and int[0].
That doesn't fit Java's inheritance model well. Now if you only have
int[4] and int[1] in the system the superclass of int[4] would be
different than if you also had int[2] in the system. Now add dynamic
class loading into the mix...
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.
I don't see anything which would prevent the realization of the feature
you are asking. The key question is: what negative side effects are
produced?
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.
Why only to "some degree"? Compile time type safety would be the only
benefit compared to the current situation. We do have runtime checks
already.
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.
Yes, but that does not give you any advantages because that property is
true for *all* arrays - already in the current version of the language.
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.
Why do you want to keep that out of the discussion? When considering
technical solutions evaluating cost vs. benefit is always an important
part of the evaluation.
I think it's clear that what you propose can be solved technically -
there's always a way. But whether a solution is desirable (i.e. is
wanted / needed) and economical (in terms of effort vs. benefit) are
major questions when it comes to realizing something.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/