Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1]. So the semantics of the refactoring are preserved in the implementation. If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2]. Fernando [1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on. On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
he... yeah, probably there are a lot of theory that says that you should have them in separated places or whatever. But in practice, people does refactors all the time and they need to have them close to their use, not lost in some paper-defined place :) Esteban On Feb 20, 2013, at 11:06 AM, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
Like in the top of the menu, along with a shortcut... Now, Renaming a class exists in Refactoring>Class Refactoring>Rename/Remove and also as Rename below the refactoring. For method refactoring, there is not the rename in the refactorings menu. So, all right, there is a whole slew of improvements possible in there as "First Impressions Count". So, how do I rename a method without refactorings? I had a look at RBChangeMethodNameRefactoring>>renameImplementors self implementors do: [:each | | parseTree | parseTree := each parseTreeFor: oldSelector. parseTree isNil ifTrue: [self refactoringFailure: 'Could not parse source code.']. self implementorsCanBePrimitives ifFalse: [parseTree isPrimitive ifTrue: [self refactoringFailure: ('<1p>''s implementation of #<2s> is a primitive' expandMacrosWith: each with: oldSelector)]]. self modifyImplementorParseTree: parseTree in: each. (each methodFor: oldSelector) compileTree: parseTree] but then saw: transform self renameImplementors. self renameMessageSends. self removeRenamedImplementors Really so complicated for a rename? Is there any place to look at? Phil 2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
he... yeah, probably there are a lot of theory that says that you should have them in separated places or whatever. But in practice, people does refactors all the time and they need to have them close to their use, not lost in some paper-defined place :)
Esteban
On Feb 20, 2013, at 11:06 AM, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
Yes, but the rename is *not* in the refactoring menu. It is *below* the refactoring menu. So, it is an unexpected refactoring in disguise... There was a simple rename in 1.4 I think. Maybe can we get that one back (in 3.0 of course...) Phil 2013/2/20 Fernando Olivero <fernando.olivero@usi.ch>:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
yes, but the debate is interesting, because is about usability... and we certainly need to improve a lot in that area. I think that currently, when people performs an operation like rename, they are waiting for a refactor, not for the clean rename (if you look at eclipse, for instance, that's what you have when you rename a method or a class)... what has become quite uncommon is to perform the "non-refactored operation". Of course we could have a place for that operation too, but since the "refactored one" is what people expects/uses, that has to be the one that will be easier to fetch. Esteban On Feb 20, 2013, at 11:25 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, but the rename is *not* in the refactoring menu. It is *below* the refactoring menu. So, it is an unexpected refactoring in disguise...
There was a simple rename in 1.4 I think. Maybe can we get that one back (in 3.0 of course...)
Phil
2013/2/20 Fernando Olivero <fernando.olivero@usi.ch>:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
Yes, usability matters. Especially to get traction with new people. Alt-R,Alt-N is perfectly usable, no matter how deep it is in the refactoring menu. Refactoring fine for dealing with a codebase. Not so when dealing with typos or removing methods from a path while at the same time not really removing them (aka rename doThis to doThis_ temporarily for example). Phil 2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
yes, but the debate is interesting, because is about usability... and we certainly need to improve a lot in that area. I think that currently, when people performs an operation like rename, they are waiting for a refactor, not for the clean rename (if you look at eclipse, for instance, that's what you have when you rename a method or a class)... what has become quite uncommon is to perform the "non-refactored operation". Of course we could have a place for that operation too, but since the "refactored one" is what people expects/uses, that has to be the one that will be easier to fetch.
Esteban
On Feb 20, 2013, at 11:25 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, but the rename is *not* in the refactoring menu. It is *below* the refactoring menu. So, it is an unexpected refactoring in disguise...
There was a simple rename in 1.4 I think. Maybe can we get that one back (in 3.0 of course...)
Phil
2013/2/20 Fernando Olivero <fernando.olivero@usi.ch>:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :) Historically (even if it sounds wrong today) you create a new method, and delete the old one (and indeed this is disturbing for new comers ^^) I really think that both usage are valid even if I think that most of the time, you want to do a refactoring while renaming :) Let's release Pharo 2.0, and then we will have fun experimenting this ^^ Ben On Feb 20, 2013, at 11:45 AM, phil@highoctane.be wrote:
Yes, usability matters. Especially to get traction with new people.
Alt-R,Alt-N is perfectly usable, no matter how deep it is in the refactoring menu.
Refactoring fine for dealing with a codebase. Not so when dealing with typos or removing methods from a path while at the same time not really removing them (aka rename doThis to doThis_ temporarily for example).
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
yes, but the debate is interesting, because is about usability... and we certainly need to improve a lot in that area. I think that currently, when people performs an operation like rename, they are waiting for a refactor, not for the clean rename (if you look at eclipse, for instance, that's what you have when you rename a method or a class)... what has become quite uncommon is to perform the "non-refactored operation". Of course we could have a place for that operation too, but since the "refactored one" is what people expects/uses, that has to be the one that will be easier to fetch.
Esteban
On Feb 20, 2013, at 11:25 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, but the rename is *not* in the refactoring menu. It is *below* the refactoring menu. So, it is an unexpected refactoring in disguise...
There was a simple rename in 1.4 I think. Maybe can we get that one back (in 3.0 of course...)
Phil
2013/2/20 Fernando Olivero <fernando.olivero@usi.ch>:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
For 2.0 could the menu item be changed from 'Rename' to 'Rename All' ? That should satisfy the Principle Of Least Surprise and be sufficient avoid newcomer going... "I've heard Pharo is cool - oh! a new release, I'll try it - Rename - WTF - DELETE!!!!!" Perhaps exaggerating but is possible. 2.0 should not be held up by small last minute issues, but if the changing the menu item is quick to implement... Also, could these last minute UI issues that don't break an API be targeted at 2.1 rather than 3.0. cheers -Ben Benjamin wrote:
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :)
Historically (even if it sounds wrong today) you create a new method, and delete the old one (and indeed this is disturbing for new comers ^^)
I really think that both usage are valid even if I think that most of the time, you want to do a refactoring while renaming :)
Let's release Pharo 2.0, and then we will have fun experimenting this ^^
Ben
On Feb 20, 2013, at 11:45 AM, phil@highoctane.be wrote:
Yes, usability matters. Especially to get traction with new people.
Alt-R,Alt-N is perfectly usable, no matter how deep it is in the refactoring menu.
Refactoring fine for dealing with a codebase. Not so when dealing with typos or removing methods from a path while at the same time not really removing them (aka rename doThis to doThis_ temporarily for example).
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
yes, but the debate is interesting, because is about usability... and we certainly need to improve a lot in that area. I think that currently, when people performs an operation like rename, they are waiting for a refactor, not for the clean rename (if you look at eclipse, for instance, that's what you have when you rename a method or a class)... what has become quite uncommon is to perform the "non-refactored operation". Of course we could have a place for that operation too, but since the "refactored one" is what people expects/uses, that has to be the one that will be easier to fetch.
Esteban
On Feb 20, 2013, at 11:25 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, but the rename is *not* in the refactoring menu. It is *below* the refactoring menu. So, it is an unexpected refactoring in disguise...
There was a simple rename in 1.4 I think. Maybe can we get that one back (in 3.0 of course...)
Phil
2013/2/20 Fernando Olivero <fernando.olivero@usi.ch>:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
On Feb 20, 2013, at 2:57 PM, Ben Coman <btc@openInWorld.com> wrote:
For 2.0 could the menu item be changed from 'Rename' to 'Rename All' ?
That should satisfy the Principle Of Least Surprise and be sufficient avoid newcomer going... "I've heard Pharo is cool - oh! a new release, I'll try it - Rename - WTF - DELETE!!!!!" Perhaps exaggerating but is possible.
As I said, If you argue on that level, we can never build something that we can release. There are (my estimation) 20.000 issues like that that we would need to fix. Marcus
Now, 19.999 left. http://code.google.com/p/pharo/issues/detail?id=7554 Slice in inbox. Phil 2013/2/20 Marcus Denker <marcus.denker@inria.fr>:
On Feb 20, 2013, at 2:57 PM, Ben Coman <btc@openInWorld.com> wrote:
For 2.0 could the menu item be changed from 'Rename' to 'Rename All' ?
That should satisfy the Principle Of Least Surprise and be sufficient avoid newcomer going... "I've heard Pharo is cool - oh! a new release, I'll try it - Rename - WTF - DELETE!!!!!" Perhaps exaggerating but is possible.
As I said, If you argue on that level, we can never build something that we can release. There are (my estimation) 20.000 issues like that that we would need to fix.
Marcus
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
Historically (even if it sounds wrong today) you create a new method, and delete the old one (and indeed this is disturbing for new comers ^^)
I really think that both usage are valid even if I think that most of the time, you want to do a refactoring while renaming :)
Let's release Pharo 2.0, and then we will have fun experimenting this ^^
Ben
On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
I am kind of aware of that :) But for a new comer, it's not obvious at all. And usually they first look in the menu and click on the first entry "matching" the need Ben
Historically (even if it sounds wrong today) you create a new method, and delete the old one (and indeed this is disturbing for new comers ^^)
I really think that both usage are valid even if I think that most of the time, you want to do a refactoring while renaming :)
Let's release Pharo 2.0, and then we will have fun experimenting this ^^
Ben
Le 20/02/2013 21:33, Benjamin a écrit :
On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse@free.fr <mailto:stephane.ducasse@free.fr>> wrote:
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com <mailto:benjamin.vanryseghem.pharo@gmail.com>> wrote:
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
I am kind of aware of that :)
But for a new comer, it's not obvious at all. And usually they first look in the menu and click on the first entry "matching" the need
Ben
What about restricting the rename to the current package or class? With, say, a box to tick to go system wide? (And a nice GUI, moose-like, showing on a color map how much of the system the rename will impact :)) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
I added this one to NautilusRefactorings basicRenameMethodFor: aMethod | class selector category oldMethodName newMethodName oldSelector newSelector newMethod source parser | class := aMethod methodClass. oldSelector := aMethod selector. oldMethodName := oldSelector asString. category := aMethod category. (newMethodName := UITheme builder textEntry: 'New method name:' asString title: 'Rename ',oldMethodName asString, ' to...') ifNil: [ ^ nil ]. newSelector := newMethodName asSymbol. oldSelector = newSelector ifTrue: [^self]. source := class sourceCodeAt: oldSelector. "Replace selector in method source" (parser := class parserClass new) parseSelector: source. source := (newSelector asString), (source allButFirst: parser endOfLastToken). "Compile modified source" class compile: source classified: category. "Remove old selector" class removeSelector: oldSelector And changed the rename menu into the NautilusUI with refactoringMethodMenu: aBuilder <nautilusGlobalMethodMenu> | target | target := aBuilder model. target selectedMethod ifNil:[ ^ target ]. (aBuilder item: #'Refactoring') order: -100. (aBuilder item: #'Rename method (basic)') action: [ | scroll | scroll := target methodWidget vScrollValue. target refactor basicRenameMethodFor: target selectedMethod. target methodWidget vScrollValue: scroll ]; order: -95. (aBuilder item: #'Rename method (all)') keyText: 'r, m' if: Nautilus useOldStyleKeys not; keyText: 'r' if: Nautilus useOldStyleKeys; action: [ | scroll | scroll := target methodWidget vScrollValue. target refactor renameMethodFor: target selectedMethod. target methodWidget vScrollValue: scroll ]; order: -90; withSeparatorAfter .... I think you can get this in Slice #7560 So, I've got what I needed. Maybe someone knowing better can make this clean. Maybe there is a way to do this with the standard refactorings system, but it was beyond me to start understanding how to do that properly. (Altough it looks like pretty cool!) Phil 2013/2/21 Goubier Thierry <thierry.goubier@cea.fr>:
Le 20/02/2013 21:33, Benjamin a écrit :
On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse@free.fr <mailto:stephane.ducasse@free.fr>> wrote:
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com <mailto:benjamin.vanryseghem.pharo@gmail.com>> wrote:
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
I am kind of aware of that :)
But for a new comer, it's not obvious at all. And usually they first look in the menu and click on the first entry "matching" the need
Ben
What about restricting the rename to the current package or class? With, say, a box to tick to go system wide?
(And a nice GUI, moose-like, showing on a color map how much of the system the rename will impact :))
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
we should not put it under refactorings. On Feb 21, 2013, at 10:54 AM, phil@highoctane.be wrote:
I added this one to NautilusRefactorings
basicRenameMethodFor: aMethod
| class selector category oldMethodName newMethodName oldSelector newSelector newMethod source parser |
class := aMethod methodClass. oldSelector := aMethod selector. oldMethodName := oldSelector asString. category := aMethod category.
(newMethodName := UITheme builder textEntry: 'New method name:' asString title: 'Rename ',oldMethodName asString, ' to...') ifNil: [ ^ nil ].
newSelector := newMethodName asSymbol. oldSelector = newSelector ifTrue: [^self]. source := class sourceCodeAt: oldSelector.
"Replace selector in method source" (parser := class parserClass new) parseSelector: source. source := (newSelector asString), (source allButFirst: parser endOfLastToken).
"Compile modified source" class compile: source classified: category.
"Remove old selector" class removeSelector: oldSelector
And changed the rename menu into the NautilusUI with refactoringMethodMenu: aBuilder <nautilusGlobalMethodMenu> | target | target := aBuilder model. target selectedMethod ifNil:[ ^ target ].
(aBuilder item: #'Refactoring') order: -100.
(aBuilder item: #'Rename method (basic)') action: [ | scroll | scroll := target methodWidget vScrollValue. target refactor basicRenameMethodFor: target selectedMethod. target methodWidget vScrollValue: scroll ]; order: -95.
(aBuilder item: #'Rename method (all)') keyText: 'r, m' if: Nautilus useOldStyleKeys not; keyText: 'r' if: Nautilus useOldStyleKeys; action: [ | scroll | scroll := target methodWidget vScrollValue. target refactor renameMethodFor: target selectedMethod. target methodWidget vScrollValue: scroll ]; order: -90; withSeparatorAfter
....
I think you can get this in Slice #7560
So, I've got what I needed. Maybe someone knowing better can make this clean.
Maybe there is a way to do this with the standard refactorings system, but it was beyond me to start understanding how to do that properly. (Altough it looks like pretty cool!)
Phil
2013/2/21 Goubier Thierry <thierry.goubier@cea.fr>:
Le 20/02/2013 21:33, Benjamin a écrit :
On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse@free.fr <mailto:stephane.ducasse@free.fr>> wrote:
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com <mailto:benjamin.vanryseghem.pharo@gmail.com>> wrote:
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
I am kind of aware of that :)
But for a new comer, it's not obvious at all. And usually they first look in the menu and click on the first entry "matching" the need
Ben
What about restricting the rename to the current package or class? With, say, a box to tick to go system wide?
(And a nice GUI, moose-like, showing on a color map how much of the system the rename will impact :))
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Sure, but this is not under refactorings in the menu. It is just that NautilusUI routes such requests to the NautilusRefactorings class. Maybe there is another place to store that. Or a need to refactor NautilusRefactorings into NautilusCommands (a true refactoring!) As I don't have a view on the design of that beast, I am at a loss here. Phil 2013/2/22 stephane ducasse <stephane.ducasse@free.fr>:
we should not put it under refactorings.
On Feb 21, 2013, at 10:54 AM, phil@highoctane.be wrote:
I added this one to NautilusRefactorings
basicRenameMethodFor: aMethod
| class selector category oldMethodName newMethodName oldSelector newSelector newMethod source parser |
class := aMethod methodClass. oldSelector := aMethod selector. oldMethodName := oldSelector asString. category := aMethod category.
(newMethodName := UITheme builder textEntry: 'New method name:' asString title: 'Rename ',oldMethodName asString, ' to...') ifNil: [ ^ nil ].
newSelector := newMethodName asSymbol. oldSelector = newSelector ifTrue: [^self]. source := class sourceCodeAt: oldSelector.
"Replace selector in method source" (parser := class parserClass new) parseSelector: source. source := (newSelector asString), (source allButFirst: parser endOfLastToken).
"Compile modified source" class compile: source classified: category.
"Remove old selector" class removeSelector: oldSelector
And changed the rename menu into the NautilusUI with refactoringMethodMenu: aBuilder <nautilusGlobalMethodMenu> | target | target := aBuilder model. target selectedMethod ifNil:[ ^ target ].
(aBuilder item: #'Refactoring') order: -100.
(aBuilder item: #'Rename method (basic)') action: [ | scroll | scroll := target methodWidget vScrollValue. target refactor basicRenameMethodFor: target selectedMethod. target methodWidget vScrollValue: scroll ]; order: -95.
(aBuilder item: #'Rename method (all)') keyText: 'r, m' if: Nautilus useOldStyleKeys not; keyText: 'r' if: Nautilus useOldStyleKeys; action: [ | scroll | scroll := target methodWidget vScrollValue. target refactor renameMethodFor: target selectedMethod. target methodWidget vScrollValue: scroll ]; order: -90; withSeparatorAfter
....
I think you can get this in Slice #7560
So, I've got what I needed. Maybe someone knowing better can make this clean.
Maybe there is a way to do this with the standard refactorings system, but it was beyond me to start understanding how to do that properly. (Altough it looks like pretty cool!)
Phil
2013/2/21 Goubier Thierry <thierry.goubier@cea.fr>:
Le 20/02/2013 21:33, Benjamin a écrit :
On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse@free.fr <mailto:stephane.ducasse@free.fr>> wrote:
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com <mailto:benjamin.vanryseghem.pharo@gmail.com>> wrote:
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
I am kind of aware of that :)
But for a new comer, it's not obvious at all. And usually they first look in the menu and click on the first entry "matching" the need
Ben
What about restricting the rename to the current package or class? With, say, a box to tick to go system wide?
(And a nice GUI, moose-like, showing on a color map how much of the system the rename will impact :))
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
I think all this topic should be quite easy. It should be similar to OB "scope". All refactors like method rename affects everything if the scope is the default. If you want to affect only a class/package do a "Browse scoped" to a class/package. And then the refactors should only affect that. Of course, we should explain this somewhere in Pharo doc. I think this is quite easy and enough for most cases. On Thu, Feb 21, 2013 at 6:45 AM, Goubier Thierry <thierry.goubier@cea.fr>wrote:
Le 20/02/2013 21:33, Benjamin a écrit :
On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse@free.fr <mailto:stephane.ducasse@free.**fr <stephane.ducasse@free.fr>>> wrote:
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@**gmail.com<benjamin.vanryseghem.pharo@gmail.com> <mailto:benjamin.vanryseghem.**pharo@gmail.com<benjamin.vanryseghem.pharo@gmail.com>>> wrote:
There is actually no simple way to simply rename a method.
We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
I am kind of aware of that :)
But for a new comer, it's not obvious at all. And usually they first look in the menu and click on the first entry "matching" the need
Ben
What about restricting the rename to the current package or class? With, say, a box to tick to go system wide?
(And a nice GUI, moose-like, showing on a color map how much of the system the rename will impact :))
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
-- Mariano http://marianopeck.wordpress.com
I like the idea :) but that's for 3.0 => add a scope selector to the changes view => add default scopes (Method/Class/SubPackage/Package/System) => add scope creator (certain methods / certain classes / certain packages) that will indeed cover almost every aspect ;) On 2013-02-23, at 16:50, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
I think all this topic should be quite easy. It should be similar to OB "scope". All refactors like method rename affects everything if the scope is the default. If you want to affect only a class/package do a "Browse scoped" to a class/package. And then the refactors should only affect that. Of course, we should explain this somewhere in Pharo doc. I think this is quite easy and enough for most cases.
On Thu, Feb 21, 2013 at 6:45 AM, Goubier Thierry <thierry.goubier@cea.fr>wrote:
Le 20/02/2013 21:33, Benjamin a écrit :
On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse@free.fr <mailto:stephane.ducasse@free.**fr <stephane.ducasse@free.fr>>> wrote:
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@**gmail.com<benjamin.vanryseghem.pharo@gmail.com> <mailto:benjamin.vanryseghem.**pharo@gmail.com<benjamin.vanryseghem.pharo@gmail.com>>> wrote:
There is actually no simple way to simply rename a method.
We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
I am kind of aware of that :)
But for a new comer, it's not obvious at all. And usually they first look in the menu and click on the first entry "matching" the need
Ben
What about restricting the rename to the current package or class? With, say, a box to tick to go system wide?
(And a nice GUI, moose-like, showing on a color map how much of the system the rename will impact :))
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
-- Mariano http://marianopeck.wordpress.com
On Feb 20, 2013, at 9:33 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
I am kind of aware of that :)
I know :) Now why not adding a bad menu item that nobody will ever use :)
But for a new comer, it's not obvious at all. And usually they first look in the menu and click on the first entry "matching" the need
Wellâ¦. stef
7560 2013/2/22 stephane ducasse <stephane.ducasse@free.fr>:
On Feb 20, 2013, at 9:33 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
I am kind of aware of that :)
I know :)
Now why not adding a bad menu item that nobody will ever use :)
But for a new comer, it's not obvious at all. And usually they first look in the menu and click on the first entry "matching" the need
Wellâ¦.
stef
http://stackoverflow.com/questions/882885/how-do-i-change-a-methods-name-dyn... is an interesting read. Phil, now more educated on the matter. 2013/2/20 stephane ducasse <stephane.ducasse@free.fr>:
On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
There is actually no simple way to simply rename a method. We should maybe add one which keep track of the versions :)
sure there is: click on the method in the text pane change the selector of the method and compile.
Historically (even if it sounds wrong today) you create a new method, and delete the old one (and indeed this is disturbing for new comers ^^)
I really think that both usage are valid even if I think that most of the time, you want to do a refactoring while renaming :)
Let's release Pharo 2.0, and then we will have fun experimenting this ^^
Ben
to rename a method without refactoring: just click on the method and in the method pan change its name and recompile Stef On Feb 20, 2013, at 11:25 AM, phil@highoctane.be wrote:
Yes, but the rename is *not* in the refactoring menu. It is *below* the refactoring menu. So, it is an unexpected refactoring in disguise...
There was a simple rename in 1.4 I think. Maybe can we get that one back (in 3.0 of course...)
Phil
2013/2/20 Fernando Olivero <fernando.olivero@usi.ch>:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
This creates another method and leaves the first one in place. 2013/2/20 stephane ducasse <stephane.ducasse@free.fr>:
to rename a method without refactoring: just click on the method and in the method pan change its name and recompile
Stef
On Feb 20, 2013, at 11:25 AM, phil@highoctane.be wrote:
Yes, but the rename is *not* in the refactoring menu. It is *below* the refactoring menu. So, it is an unexpected refactoring in disguise...
There was a simple rename in 1.4 I think. Maybe can we get that one back (in 3.0 of course...)
Phil
2013/2/20 Fernando Olivero <fernando.olivero@usi.ch>:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
For me the issue is not so much whether there there is another way to rename, but that it is "an _unexpected_ refactoring in disguise" -ben stephane ducasse wrote:
to rename a method without refactoring: just click on the method and in the method pan change its name and recompile
Stef
On Feb 20, 2013, at 11:25 AM, phil@highoctane.be wrote:
Yes, but the rename is *not* in the refactoring menu. It is *below* the refactoring menu. So, it is an unexpected refactoring in disguise...
There was a simple rename in 1.4 I think. Maybe can we get that one back (in 3.0 of course...)
Phil
2013/2/20 Fernando Olivero <fernando.olivero@usi.ch>:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
For me the issue is not so much whether there there is another way to rename, but that it is "an _unexpected_ refactoring in disguise"
yes I hate it. Stef
-ben
stephane ducasse wrote:
to rename a method without refactoring: just click on the method and in the method pan change its name and recompile
Stef
On Feb 20, 2013, at 11:25 AM, phil@highoctane.be wrote:
Yes, but the rename is *not* in the refactoring menu. It is *below* the refactoring menu. So, it is an unexpected refactoring in disguise...
There was a simple rename in 1.4 I think. Maybe can we get that one back (in 3.0 of course...)
Phil
2013/2/20 Fernando Olivero <fernando.olivero@usi.ch>:
Hi, i had the same misconception once, but i recall Lukas pointed out that the refactoring engine is built on the original refactoring's from Fowler's book, and implemented in Smalltalk by Roberts and Johnson [1].
So the semantics of the refactoring are preserved in the implementation.
If you just want a method rename, not a method refactoring rename, maybe is best have an option for that in the menu [2].
Fernando
[1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf [2] or use a better widget for editing methods, than a simple code editor within the pane of the browser, as in Gaucho..which i'm working on.
On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... It is a small step, but is something... and well... we can improve in next releases, one step at a time :)
Esteban
On Feb 20, 2013, at 10:52 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Yes, thanks, I figured that out. A newcomer wouldn't... and renaming is pretty common.
What will happen is that people will remove the method and recreate a new one. Version history will then go away.
Or is the system smart enough to find out about these things?
Phil
2013/2/20 Esteban Lorenzano <estebanlm@gmail.com>:
hi,
yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image.
cheers, Esteban
On Feb 20, 2013, at 10:21 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
Well, look at the screenshot then tell me that this is what I want.
It is definitively *not* what I want. Especially unchecking that endless list of methods.
Adding a "Uncheck all" "Check all" button to the Changes Browser list would help...
Regards Phil
2013/2/20 Camillo Bruni <camillobruni@gmail.com>:
there is 1 certain bug, that is that you cannot see the changes of the refactoring:
https://code.google.com/p/pharo/issues/detail?id=7547
the rest I would consider a bug as well. But in the terms of refactoring it might be "valid". It does preserve behavior by renaming also all implementors.
How about this reasoning:
Rename method => rename all senders (since you refactor) => you have to rename all implementors as well since you renamed all send sites otherwise you'll run for sure into a DNU
I think I just convinced myself :D
On 2013-02-20, at 09:26, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was doing a Refactoring>rename of the initialize method in Nautilus for the ClassMethodBrowser and then the changes browser proposed me to change all classes with initialize. WTF?
Phil
<PharoScreenshot.3.png>
participants (10)
-
Ben Coman -
Benjamin -
Camillo Bruni -
Esteban Lorenzano -
Fernando Olivero -
Goubier Thierry -
Marcus Denker -
Mariano Martinez Peck -
phil＠highoctane.be -
stephane ducasse