Make class abstract driver

[hernanmd]

This PR implements the "Make Abstract" class refactoring using the new Driver interface.

Make RBAbstractClass match the MOP answering both false by default in #isAbstract. Migrate RBMakeClassAbstractTransformation. Add data for testing: #RBClassWithoutSelfClassReferenceTest and #RBWithSelfClassReferenceTest Update RBMakeClassAbstractParametrizedTest Add #RBMakeClassAbstractDriver with tests Update #SycCMakeAbstractCommand

[Ducasse]

What is the logic of this refactoring? I mean I do not really understand what is an abstract class in pharo and when i will need it.

[hernanmd]

I migrated because it was there and some people may be using it.

However, I never bought the arguments for "improving code clarity" or "preventing improper instantiation" (maybe they're good for educational purposes), so I'll provide an example where I used it some time ago as a dirty experiment: To migrate a legacy system, using automated scripts, some classes couldn't be migrated to the new system. To get a quick diff of which ones weren't migrated, I annotated the already migrated abstract classes with the "isAbstract" method, so I could later see which hierarchies have fewer subclasses than expected.

If there are other use cases I would have to think about them because as you said, there doesn't seem to be too many.

[MarcusDenker]

I use it a lot, it is useful for the Browser and the Rules to know that a class is abstract. Imagine having a subclassResponsibility method. The browser nags you to implement it, but the subclass is Abtract, too. So we could add the method again, then it complaints that the method is the same as in the superclass.

=> add #isAbstract, and the Browser/Rules know that you do not have to implement the #subclassResponsability here and just ask you to implement it where you want it

[jecisc]

I also like to know easily when a class is abstract when I'm exploring a project I'm not familiar with. Like that I'm able to understand the structure of the project more easily.

And I know that I should not instantiate those classes but just look at the subclasses.

[jecisc]

CI got a random failure. I'm restarting it

[hernanmd]

Thanks Cyril, it seems that failing tests are not related:

[jecisc]

Some tests are refactoring related so it's possible it comes from here no?

[hernanmd]

Some tests are refactoring related so it's possible it comes from here no?

Ok, I fixed the failing tests. Now it seems good to go

https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pending%20pull%20request%20and%20branch%20Pipeline/detail/PR-16347/6/tests

Jenkins