2017-07-28 14:12 GMT+02:00 Stephane Ducasse <stepharo.self@gmail.com>:

Tx denis.

I like the scoped refactoring :). Do you have settings for all the automatic protocols?

No. Now they depends on installed plugins. But do we need it? because it is like inspector extensions. We have no settings for them. Maybe setting for critiques will be important because there were lot of problems with updating critic method group. But I hope that this version solves them all.

BTW do you kept the inplace edit of protocol? Because it was cool to double click on it to rename it.

Also not implemented.

Stef

On Fri, Jul 28, 2017 at 10:58 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

...

Hi.

I moved Calypso to github https://github.com/dionisiydk/Calypso. You can load it with following script:

Metacello new baseline: 'Calypso'; repository: 'github://dionisiydk/Calypso'; load

Now you can fork it and pull requests to dev branch.

New version includes a lot of new features and fixes. You can read overview in my blog http://dionisiydk.blogspot.fr/2017/07/calypso-update-many- improvements-and.html

Best regards, Denis

I like the scoped refactoring :).

I hope it was clear that it is in todo. I just shared idea how it will be done.

Hi Thierry 2017-07-28 15:01 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

Hi Denis,

So it's post-refactoring that you scope, not pre-refactoring?

post-refactoring: refactor, then restrict (scope) to what it is applied pre-refactoring: restrict (scope) first, then refactor, then apply

Post/pre distinction looks strange because they both not change anything in image. But I understand what you are talking about. So it will be pre-refactoring on current scope (full image by default). And change browser will allow choose different scope which will reevaluate refactoring again and update shown changes.

Or would both be available?

Thierry

2017-07-28 14:43 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

...

I like the scoped refactoring :).

I hope it was clear that it is in todo. I just shared idea how it will be done.

But I understand what you are talking about. So it will be pre-refactoring

...

on current scope (full image by default). And change browser will allow choose different scope which will reevaluate refactoring again and update shown changes.

Understood. Will enlarging the original scope be possible? Yes. When new method browser is spawned it includes all scopes of original browser. If you spawn senders from class references which are restricted by package then new browser will show senders in scope of this package. But it will also include all scopes of original browser in scopes list. So you are always able switch to full image or other scope which you are used in other "parent windows".

On 07/28/2017 08:29 AM, Denis Kudriashov wrote:

Hi Thierry

2017-07-28 15:01 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:

Hi Denis,

So it's post-refactoring that you scope, not pre-refactoring?

post-refactoring: refactor, then restrict (scope) to what it is applied pre-refactoring: restrict (scope) first, then refactor, then apply

Post/pre distinction looks strange because they both not change anything in image. But I understand what you are talking about. So it will be pre-refactoring on current scope (full image by default). And change browser will allow choose different scope which will reevaluate refactoring again and update shown changes.

I haven't been keeping up on the discussion so I may be way off... However, if you are using the scoping that is already built into the RB's refactorings, then it is pre-refactoring (i.e., they don't look at code outside the scope). BTW, if you use post-refactoring, then things like safe remove method wouldn't work since calls outside the scope would cause the refactoring to abort without removing the method. John Brant