[Ann] New deprecations API
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
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
participants (2)
-
Denis Kudriashov -
Richard O'Keefe