Hi all,
as you might have noticed, I spent some time on decorating various methods
with #deprecated that are in deprecation packages.
I am wondering what the general "rule" or at least desire about deprecated methods is. Would you agree the following guideline?
"A method should be in a *Deprecated* method category if and only if it calls #deprecated or any overload of that."
If this is correct, I wrote two tests to check both directions of this rule. I would propose to put them into ReleaseTest:
testDeprecatedMethodsAreInDeprecatedPackages
CompiledMethod allInstances
select: [:method | method isInstalled]
thenDo: [:method |
| category |
category := method methodClass whichCategoryIncludesSelector: method selector.
(method isDeprecated and: [category notNil]) ifTrue: [
self assert: [category name includesSubstring: 'Deprecated']]].
testMethodsInDeprecatedPackagesAreDeprecated
CompiledMethod allInstances
select: [:method | method isInstalled]
thenDo: [:method |
| category |
category := method methodClass whichCategoryIncludesSelector: method selector.
category name ifNotNil: [:name |
(name includesSubstring: 'Deprecated') ifTrue: [
self assert: [method isDeprecated]]]].
Or are there any special cases where we would like to preserve a different deprecation state between category and literal indication?
For example, SequenceableCollection>>#upTo: breaks the first test. Does this method belong into *60Deprecated?
For the other test, respecting the latest inbox commits there is only one violation (FancyMailComposition>>#mvcOpen).
(How) should we solve that? With Project>>#tellAFriend:, this method actually has a non-deprecated sender.
Is #tellAFriend: still relevant? Maybe we could restrict
FancyMailComposition to Morphic, according to its package name.
In general, I find its placement quite confusing: The class category name consists of both 'MorphicExtras' & 'Etoys', which usually seem to be separated (or, respecting Squeakland, at least combined the other way round). There are two different UI
methods (#morphicOpen and #openInMorphic) without any clear distinction. Despite of the name 'morphic', the MVCUIManager depends on this class (and #mvcOpen depends on MVC, vice versa).
Looking forward to your answers :)
Christoph
Locked
