About MoveToClassSideTransformation

[Ducasse]

Right now RBMoveMethodsToClassSideDriver is implemented as:

scopes: scopesList methods: methods

	scopes := scopesList.
	model := self refactoringScopeOn: scopesList first.
	refactoring := ReCompositeRefactoring new
		               model: model;
		               refactorings: (methods collect: [ :m |
					                RBMoveMethodToClassSideRefactoring
						                model: model
						                method: m
						                class: m origin ])

Let us imagine for a while that we would use RBMoveMethodToClassSideTransformation instead of RBMoveMethodToClassSideRefactoring (see the other issue on the fact that RBMoveMethodToClassRefactoring is not one).

Now let us imagine that we have a class X with two methods m1 and m2 and that the class Y define m2.
With this semantics we will get in trouble because m1 will be moved and the system will break on m2.

So we should check all the precondition upFront and if one is already defined in the target class.
In batch mode with do not do it.
In interactive mode the driver should ask what to do.

@balsa-sarenac what do you think?

Ideally I have the impression that I would also define a separate for doing the transformation.

[balsa-sarenac]

I agree, it's hard to figure out these cases, good that you noticed. I like that we have more and more examples of ReUpFrontPreconditionCheckingRefactoring.

[Ducasse]

Yes this is what I like :)
I plan to make MoveToClassSide not a subclass of MoveToClass and also have a transformation and a refactoring clearly working.