Helping to find the usefulness of a proposal
David Goodenough
david.goodenough at linkchoose.co.uk
Thu Apr 2 06:07:21 PDT 2009
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.
field names in strings (binding frameworks, SQL and Criteria strings, and
PropertyChangeSupport events). You could always just build a list of
fields and look for all strings that contained those string values (they might
be EL strings, or parts of an SQL statement), but I think you would come
up with a large number of false positives. There are plenty of instances
of this out there, but I am not at all sure how you would count them
accurately.
This lack of ability to check them was of course the point of needing a
solution.
David
More information about the coin-dev
mailing list