This PR changes much of way RangeMap is built and how RangeAplier uses it to process java source file. RangeMap specification stays same.
At first, it changes data model of RangeMap:
RangeMap now stores elements hierarchically
RangeMap starts with abstract structure called ROOT
each structure can store other structures (children) and entries (also children) and so on
this hierarchy is an reflection of this what is stored in range file
Secondly, this changes RangeApplier to process RangeMap:
starting from ROOT structure
getting all childrens (structures and entries)
and processing them recursively
By processing it mean:
sorting children (as IRange) by start position to proper shifting data (important)
processing each child with [StructuralEntry/RangeEntry]Processor based on type:
= if child is just RangeEntry it does same action like previously - replaces text occurence in output string
= if child is a StructuralEntry it does processing "from start" (like starting from ROOT)
In each case all tests passes. It needed to correct some patterns (misplaced entries).
I don't know how you planned to do this kind of feature, but i think my solution will be very comfortable to expand processing functionality in future. This is good start to other features such:
This PR changes much of way RangeMap is built and how RangeAplier uses it to process java source file. RangeMap specification stays same.
At first, it changes data model of RangeMap:
Secondly, this changes RangeApplier to process RangeMap:
In each case all tests passes. It needed to correct some patterns (misplaced entries).
I don't know how you planned to do this kind of feature, but i think my solution will be very comfortable to expand processing functionality in future. This is good start to other features such:
If something is unclear or need to correct, please give me feedback.