Le 1 sept. 2015 à 09:37, Marcus Denker a écrit : > >> 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.
perfect :) > 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 ;-) with the support you will provide for deprecations, for sure, you will be able to deprecate a lot more things. People will care less because there will be support to convert their code.
smime.p7s
Description: S/MIME cryptographic signature
