Removing a Trait creates remove event entries in Epicea for all methods in TraitedClass

[chisandrei]

Bug description
Removing a Trait creates remove event entries in Epicea for all methods in TraitedClass.

To Reproduce
Create a trait with no methods and then remove it.

Expected behavior
Expected behaviour is for Epicea to show one entry for the Trait that was removed.

Screenshots

Version information:
-Pharo-13.0.0+SNAPSHOT.build.682.sha.e698f2016913f479cbb80dee1008a01ca1fa30ac (64 Bit)

[jecisc]

This comes from EpMonitor>>#behaviorRemoved: that consider all methods from a class/trait are removed on the class removal.
And those methods are added in the method dict of the traits for them to work.

I guess that the same problem is happening if we remove a class using a trait. It'll probably log the removal of those methods.

We could reject those methods here, but I think this is a problem we should fix at a more global level. For example, if we look for one of those methods in the spotter, we get one result for each traits or class using a trait from the system. So probably we should introduce a way to filter those methods and fix multiple places with this problem

[chisandrei]

@jecisc Yes, they come from EpMonitor>>#behaviorRemoved:. We added for now a different way to get only the user defined methods from aTraitedMetaclass.

TraitedMetaclass>>#metaMethods
	"Answer the receiver's methods, rejecting methods defined by TraitedClass, which have been added to the receiver's method dictionary."

	^ self methods reject: [ :each | | traitSource |
		traitSource := each traitSource
			ifNil: [ nil ]
			ifNotNil: [ :aTraitCompositionElement |
				(aTraitCompositionElement
					traitDefining: each selector
					ifNone: [ nil ]) innerClass ].
		traitSource = TraitedClass ]

Getting the methods defined by TraitedClass when calling methods on a TraitedMetaclass was suprizing. But I think that is needed because of the method lookup.