Migrate Refactoring for Generating Equal and Hash Methods

[hernanmd]

Description

This PR migrates the refactoring browser for generating #= and #hash methods to the new driver interface. The new interface provides a more streamlined and extensible approach for generating these methods, making it easier to maintain and enhance the functionality in the future.

Motivation

The existing implementation of the refactoring browser for generating #= and #hash methods was tightly coupled with the user interface (UI) code and did not prevent overwriting the existing implementation of such methods (#16361). By separating the core logic from the UI, we can improve the code's maintainability and testability and enable future enhancements or alternative user interfaces.

Implementation.

The implementation of this PR involves the following steps:

• Create a new driver interface: A new driver interface, ReGenerateEqualAndHashDriver, has been introduced. This interface defines the contract for generating #= and #hash methods, encapsulating the core logic for this functionality.
• Implement the driver: The driver uses RBGenerateEqualHashTransformation for the underlying logic.
• UI interaction: The driver uses SpSelectMultipleDialog for selecting the variables used in the generated #= and #hash methods.
• Created tests: Tests related to the generation of #= and #hash methods have been provided in ReGenerateEqualAndHashDriverTest

[Ducasse]

@balsa-sarenac can you have a look? Tx

[Ducasse]

Yes

[Ducasse]

Sounds good to me.
Potentially the other menuString should be revisited.
But I will integrate the PR right now.

[hernanmd]

Sounds good to me. Potentially the other menuString should be revisited. But I will integrate the PR right now.

Thanks

[demarey]

@hernanmd The renaming is not good: Reprefix si used by Renraku classes (critics).
Also, we now have some release tests failing :

the following classes have unused instance variables and should be cleaned:ReClassForGeneratingEqualAndHashExistingImplementors ReClassForGeneratingEqualAndHash

ReleaseTest.testThatThereAreNoSelectorsRemainingThatAreSentButNotImplemented
 'ReClassForGeneratingEqualAndHashExistingImplementors>>#=

[hernanmd]

ReClassForGeneratingEqualAndHashExistingImplementors

Thanks for reporting, Christophe.
Would you like me to fix it in another PR?

We should probably discuss the Re prefix (as taken by Renraku) with @Ducasse.

[hernanmd]

ReClassForGeneratingEqualAndHashExistingImplementors

Ok, I checked. Those instance variables are on purpose, so I added a Manifest.
(I cannot re-open the PR)

[demarey]

ReClassForGeneratingEqualAndHashExistingImplementors

Ok, I checked. Those instance variables are on purpose, so I added a Manifest. (I cannot re-open the PR)

Thank you for checking Hernan!

[demarey]

ReClassForGeneratingEqualAndHashExistingImplementors

Thanks for reporting, Christophe. Would you like me to fix it in another PR?

We should probably discuss the Re prefix (as taken by Renraku) with @Ducasse.

yes, I think it would be better to use another prefix. When you agree on a prefix, you can issue a new PR for it.

[Ducasse]

Why this is a problem to have two projects with the same prefix.
We could have ren for renraku and re for refactoring engine

[demarey]

Having the same prefix for different projects just add confusion even if technically, it does not change anything.
People are used to identify the project of a class by checking the prefix

[MarcusDenker]

This PR was merged but it had failing tests, among them:

• [CI] failing test: testNoUnusedInstanceVariablesLeft [CI] failing test: testNoUnusedInstanceVariablesLeft #16824
• [CI] testThatThereAreNoSelectorsRemainingThatAreSentButNotImplemented [CI] testThatThereAreNoSelectorsRemainingThatAreSentButNotImplemented #16825

[MarcusDenker]

I sadly can not even revert the PR as this is now so long ago that it was merged