sageserpent-open
commented
4 months ago Removed Match.dominantElement and have cutover the migration implementation to use sets of matches rather than sets of dominant elements as the key to refer to a MoveDestinations, this is complete in 7264dc180d6e669cafe6e097ffac0d234c49d015.
Did some manual testing using the Amercium and Kinetic Merge repositories to see if anything is broken, both look fine.
Two things left to do:
Update the design documentation.DONETry to rationalise the use ofDONEMatchesContext.matchesForoutside the class inCodeMotionAnalysisExtension. That client class already passes in the lambda when constructingMatchesContext, so why does it need to reference it from the constructed instance?
Said method was anticipated (and for a long time, actually used) as a way of resolving priority for when a match can contribute two or three sections from the base, left and right to the output of a merge. Which one should it go for, as they are equivalent enough to constitute a match?
In the end,
Resolutiontook over that job, but not before various tests and the migration mechanism drifted into using the dominant element as a way of modelling what makes one match different from another / the signature of the loosely-shared content of a match.The problem is that the documentation for that method is out of date, and the notion of match state uniqueness versus a content signature is not always consistent.
Review the codebase and sort this out - keep it (and update the documentation) and / or add in a replacement technique where appropriate.