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