Re: [Pharo-users] [Ann] New deprecations API

DK
Denis Kudriashov
Tue, Feb 3, 2026 10:13 AM

Hi Richard.

Not sure I understand your question.
But I think there is no difference with the old deprecation approach

вт, 3 февр. 2026 г. в 07:04, Richard O'Keefe raoknz@gmail.com:

Nice.
What happens when there are uses of a deprecated method in files held in a
repository
but not currently loaded into the image?
How does one get rewrite rules applied to a bunch of files?

On Tue, 3 Feb 2026 at 11:22, Denis Kudriashov via Pharo-users <
pharo-users@lists.pharo.org> wrote:

Following the release of BPatterns
https://github.com/dionisiydk/BPatterns
, I am happy to share another
idea that naturally grows out of it: simplifying deprecations in Pharo.

Today’s deprecations are powerful but verbose—string-based rewrite rules,
duplicated selectors, and boilerplate that most of us copy from examples.

With BPatterns, all of this can be eliminated:

Object>>confirm: queryString
^ self *deprecatedBy: * [ ConfirmationRequest signal: queryString
]

Deprecation is now expressed in the same language as the code itself, not
in a separate, string-based mini-language. There is no need to think about
transformation rules—they are part of the system and enabled by default.

Zero boilerplate.
No duplicated code
For more details and comparison with current API see the blog post:

-
https://dionisiydk.blogspot.com/2026/02/deprecations-as-they-should-be.html
Hi Richard. Not sure I understand your question. But I think there is no difference with the old deprecation approach вт, 3 февр. 2026 г. в 07:04, Richard O'Keefe <raoknz@gmail.com>: > Nice. > What happens when there are uses of a deprecated method in files held in a > repository > but not currently loaded into the image? > How does one get rewrite rules applied to a bunch of files? > > On Tue, 3 Feb 2026 at 11:22, Denis Kudriashov via Pharo-users < > pharo-users@lists.pharo.org> wrote: > >> Following the release of *BPatterns >> <https://github.com/dionisiydk/BPatterns>*, I am happy to share another >> idea that naturally grows out of it: *simplifying deprecations in Pharo*. >> >> Today’s deprecations are powerful but verbose—string-based rewrite rules, >> duplicated selectors, and boilerplate that most of us copy from examples. >> >> With BPatterns, all of this can be eliminated: >> >> Object>>confirm: queryString >> ^ self *deprecatedBy: * [ ConfirmationRequest signal: queryString >> ] >> >> Deprecation is now expressed in the same language as the code itself, not >> in a separate, string-based mini-language. There is no need to think about >> transformation rules—they are part of the system and enabled by default. >> >> Zero boilerplate. >> No duplicated code >> For more details and comparison with current API see the blog post: >> >> >> - >> https://dionisiydk.blogspot.com/2026/02/deprecations-as-they-should-be.html >> >>