Yuriy had an idea that QualityAssistant would offer option to rewrite your code, when you are sending a deprecated message. So you would have MyObject>>myMethod self deprecated: 'whatevs' rule: RewriteToolRule and then in your code which sends this method, the QA would inform you of the deprecation and offer you rewrite. This is safe (it shows Changes dialog first), and practical, because you can publish the rewrite rules as part of your code and users can update easily whenever they are ready. Peter On Tue, Sep 1, 2015 at 9:37 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 01 Sep 2015, at 09:30, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Le 1 sept. 2015 à 08:35, Marcus Denker a écrit :
On 01 Sep 2015, at 08:30, stepharo <stepharo@free.fr> wrote:
I do not get why you want to link the rewrite engine with deprecation
at runtime.
We should not have such dependencies. To me it is insane.
It can be made pluggable, of course. I donât want to have that there in a way that it requires the refactoring engine to be present all the time.
If itâs there â> transform. If not â> do what it does now.
But just think how much this simplifies the experience of people loading old code into a new Pharo version: it just keeps running and fixes itself! Itâs that kind of things we need to be able to evolve the system.
Imagine, this is a functionality (I think) no other system has!
I will not like a feature where it transforms my code without asking.
Yes, I want to have a dialog as a default, too. It should have the possibility to review, to do your own change *and* to continue and turn off the dialog for future transforms of this session.
But it is good to know that people donât think this is that important. The result is that I will deprecate things with far less guilt using the current scheme ;-)
Marcus