Skip to content

Conversation

@theWituch
Copy link
Contributor

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:

If something is unclear or need to correct, please give me feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant