Helping to find the usefulness of a proposal

[Mark Thornton]

David Goodenough wrote:
> On Thursday 02 April 2009, Stephen Colebourne wrote:
>   
>> All,
>> One possible way I'd like to suggest that the coin evaluation could be
>> helped would be to write a script to find out how frequently the
>> specific issue comes up in real code.
>>
>> It should be possible to devise, write and run a script to find the
>> number of LOCs affected by many of the proposals. For example:
>>
>> - strings in switch (find if else on constant strings)
>> - multi-catch (find duplicate catch blocks)
>> - elvis operator (find ternary and if else defaulting)
>> - for each where the iterator remove can be accessed (% of loops that
>> access iterator)
>> - for each where index is needed (% of loops that use int looping)
>> - method and field literals
>> - byte and short literals
>> and probably many others (I've just listed some proposals I remember)
>>
>> Ideally, any script would be ASM/BCEL based, but grep style might work too.
>>
>> I mention all this because I don't have the spare time to write such a
>> script, but if you do, then I'm sure we'd all like to run it and
>> discuss the results ;-)
>>
>> Stephen
>>     
>
> As a matter of interest, how would you go about finding the instances of
> the problem that my lightweight properties proposal aims to solve, i.e.
>   
There are a number of types of change which are hard to verify or 
quantify using existing code. For example escape analysis may fail to 
show benefits from eliminating allocation because the programmers have 
already done it manually. In particular they might have used integer 
loops instead of an iterator when looping over an ArrayList. I still 
have quite a few old style loops simply because there hasn't been a 
sufficiently good reason to change them yet.

Mark Thornton