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 <[email protected]>: > 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 < > [email protected]> 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 >> >>
