Deprecations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Deprecations

Christoph Thiede

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


Carpe Squeak!