Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!nx01.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: enhance an array's static type by a lower length-bound. Date: Wed, 17 Aug 2011 20:42:19 +0200 Lines: 52 Message-ID: <9b2gcfFcg7U1@mid.individual.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net CapzOfUjbqYjDFZOVtt1gQ04+79/+bvJtMvdoxDNvIa1LRaxc= Cancel-Lock: sha1:M7MR+0xGHEl5x0EMNxDHggHXcAE= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7165 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. Also there is probably a whole lot of issues with java.lang.reflect. > 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. What you propose would be useful only if the added property of arrays would allow for *compile time* checking - 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; because depending on the complexity of expr it might not be possible for the compiler to determine the guaranteed min length of a1. And finally the question: how often do you know the array length in advance? How useful is this in practice? I have the feeling that people would use this as a lazy shortcut for defining a class with n integer fields. And then how does the usefulness weight against the cost of realizing this? I think your intuition (that we won't see this) was pretty good already. :-) Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/