Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Hi Paul, while looking more detailed at the internals of component.java, I found the code not easy to understand due to many abbreviations to one or two letter variables. I refactored the names to be more descriptive, and where it makes sense, I bunched logical groups of statements into private functions (methods). That way, the intention of the code is easier to read, while the functionality remains unaltered.
I checked that nothing changed by doing many of the test procedures you created. Will continue until I have tested them all, so I can be sure my refactor had no effect on the functionality.
I did not do all of the program, just enough so I can understand more easily what is going on.
Could you please have a look at the code, and check whether you agree to the way I changed the code? If not, I can always revert to the old code.
Let me know what you think.
P.S. Still working on the exception handling.
Kind regards, Guus.
J. Paul Morrison
I guess you like longer variable names - I agree - when I am going at speed I tend to cut down on the typing! Looks fine to me - I assume that you used refactor/rename a lot, and also that the result works! I confess I'm not very proud of the way annotations and network definitions interact - a bit of a mess, I'm afraid! Sorry to put you through it, but many thanks! P.
Actually I don't really mind the annotations processing, but now that you mention it, the setup of component could probably benefit from a more thorough refactoring. Especially factoring out things that are not really "core business" for component.
For the time being I think exception handling is more important, so I will just leave that be.
Also, I am pretty interested in the discussion with John Cowan: he is a pretty knowledgable guy.