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