I think the approach would be to extend the validation done
at build time to include a check for missing accessors. Then
lets fgiure out how QuickFix works so we can implement the
accessors at a user's request.
*barrier 1* extend property specification validation to
include check for accessors
- not difficult in theory - more concerned on the
performance hit
- could use ThreadLocal caching appraoch already used for
ResourceLocations to mitigate the perfomance hit.
*barrier 2* To use Quick Fix the markers must carry enough
info to suggest the fix
- extend markers with a "fixcode", "fix suggestion" -
fixcode could, in this case, contain an enum like
GEN_ABS_ACCESSORS and fix suggestion contains enough info
for a fix command to be built
*barrier 3* Need a fix command that can examine a code and
data to generate fix suggestions - one for each modifiable
class in the component's class hierachy.
*barrier 4*
- need to be able to modify Java source the *Eclipse Way*
*barrier 5* Need a QuickFix Resolver (wrong name) registered
as an extension to use the fix command in barrier 3 to
generate and Display QuickFix suggestions.
Analysis
barrier 1 - easy
barrier 2 - easy
barrier 3 - medium
barrier 4 - hard - must learn how to do it the Eclipse Way
barrier 1 - easy
Result: Something to be looked into. All new features are on
hold (can't find the link to the reason right now) but it's
good to do this analysis for when the time comes!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=387057
Thinking about this one.
I think the approach would be to extend the validation done
at build time to include a check for missing accessors. Then
lets fgiure out how QuickFix works so we can implement the
accessors at a user's request.
*barrier 1* extend property specification validation to
include check for accessors
- not difficult in theory - more concerned on the
performance hit
- could use ThreadLocal caching appraoch already used for
ResourceLocations to mitigate the perfomance hit.
*barrier 2* To use Quick Fix the markers must carry enough
info to suggest the fix
- extend markers with a "fixcode", "fix suggestion" -
fixcode could, in this case, contain an enum like
GEN_ABS_ACCESSORS and fix suggestion contains enough info
for a fix command to be built
*barrier 3* Need a fix command that can examine a code and
data to generate fix suggestions - one for each modifiable
class in the component's class hierachy.
*barrier 4*
- need to be able to modify Java source the *Eclipse Way*
*barrier 5* Need a QuickFix Resolver (wrong name) registered
as an extension to use the fix command in barrier 3 to
generate and Display QuickFix suggestions.
Analysis
barrier 1 - easy
barrier 2 - easy
barrier 3 - medium
barrier 4 - hard - must learn how to do it the Eclipse Way
barrier 1 - easy
Result: Something to be looked into. All new features are on
hold (can't find the link to the reason right now) but it's
good to do this analysis for when the time comes!