Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder4.news.weretis.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.lang.java.programmer From: Andreas Leitgeb Subject: Re: enhance an array's static type by a lower length-bound. References: <9b2gcfFcg7U1@mid.individual.net> <9b6vg2F6hsU1@mid.individual.net> Reply-To: avl@logic.at User-Agent: slrn/pre0.9.9-111 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: 20 Aug 2011 17:20:40 GMT Lines: 82 NNTP-Posting-Host: gamma.logic.tuwien.ac.at X-Trace: 1313860840 tunews.univie.ac.at 71616 128.130.175.3 X-Complaints-To: abuse@tuwien.ac.at Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7267 Robert Klemme wrote: > On 18.08.2011 23:44, Andreas Leitgeb wrote: >> e.g.: >> void foo(int[] ia) { ... } >> void foo(int[10] ia) { ... } >> void foo(int[20] ia) { ... } > How likely is it that you want to have vastly different implementations > of foo() with different array lenghts? Very unlikely :-) (see later in this posting about benefits) >> 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. So far so good. > 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... If, for using (say) int[4200000], the JVM would really need all the 4200000 other array-"superclasses" in memory at once, then this might just be one such show-stopper that I searched for. Thanks :-) Maybe it could be fixed with some special case, where the superclasses of a bounded array-class do not really need to be in memory, but this would surely require a much deeper change than what I anticipated for it. >>> 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. "To some degree": The compiler would only check assignment to bounded arrays. (including the assignment that kind-of-happens to the formal parameters of the called method) Thus, the compiler could make sure, that a method taking a bounded array would never get called with a smaller one (but could still get null, btw). The compiler would however *not* check the particular indexing operations, (therefore I wrote: "to some degree") as the array might be larger and indices higher than the lower bound might just be legal. > 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. Sometimes these two aspects are evaluated separately. The benefit has already been evaluated as near-zero, because most arrays in practical use (those used internally for certain collections) just do not benefit from a lower bound on length. The only usecases so far were algorithms on arrays that require a particular minimum length (such as obtaining the mean value), and the anti-pattern of mis-using arrays to store separate fields. Now, I'm evaluating the cost, and it is already higher than what I expected (due to the JVM requiring complete chains of classes up to Object). The quest to find further costs would be less verbose, if the question about benefit weren't always re-raised. > I think it's clear that what you propose can be solved technically - There's changes that (would) take a straight-forward effort to implement, and there are changes that require some kind of wider refactoring. I'm curious about the latter ones that would be necessary for implementing that pseudo-proposal. Just for the sake of the discussion, actually, as I already pointed out in the first post of this thread.