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 <[email protected]>
wrote:
>
> > On 01 Sep 2015, at 09:30, Christophe Demarey <
> [email protected]> wrote:
> >
> >
> > Le 1 sept. 2015 à 08:35, Marcus Denker a écrit :
> >
> >>
> >>> On 01 Sep 2015, at 08:30, stepharo <[email protected]> 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
>
>
>
>
