Progress Report -> Refactoring Project - ( February 1 - 5 )
Hi all Last week I did these tasks: - Expose variable refactoring commands in source context ( https://github.com/pharo-project/pharo/pull/8472) - Improve messages of push up method refactoring, also add the option to push up referenced instance variables ( https://github.com/pharo-project/pharo/pull/8531) - Introduce a new way to move the method to class side refactoring ( https://github.com/pharo-project/pharo/pull/8532) - Add rename package refactoring ( https://github.com/pharo-project/pharo/pull/8533) Tasks for this week: - Improve extract setUp refactoring. - Fix previews of extract method with arguments ( https://github.com/pharo-project/pharo/issues/5855). - Improve renaming method refactoring, to only rename senders in specific packages (https://github.com/pharo-project/pharo/issues/8513) - Fix move to component issue ( https://github.com/pharo-project/pharo/issues/8499) Cheers, Evelyn
Wonderful to have progress on this important topic - thank you! Sorry I haven't been following closely (maybe you addressed it already), but pushing up instance variables has a dangerous limitation - instances lose any data held in that var. I guess it's because it's deleted from the subclass prior to adding to the superclass to avoid duplicating. One solution would be to add a var to the superclass with a mangled name, copy the data for all instances, remove the var from the subclass, and then rename the mangled var. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
I never thought of that implication - if ivars are proper objects (is that now applied?) would this issue go away (an ivar would just get a new parent)? This is a very interesting problem, as its a type of transaction, and I never though of it that way - its easy to think of it as just dumb code - but in effect it isnât. Tim On Fri, 12 Feb 2021, at 4:30 PM, Sean P. DeNigris wrote:
Wonderful to have progress on this important topic - thank you!
Sorry I haven't been following closely (maybe you addressed it already), but pushing up instance variables has a dangerous limitation - instances lose any data held in that var. I guess it's because it's deleted from the subclass prior to adding to the superclass to avoid duplicating. One solution would be to add a var to the superclass with a mangled name, copy the data for all instances, remove the var from the subclass, and then rename the mangled var.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Tim, you may want to have a look at Preserving Instance State during Refactorings in Live Environments https://hal.archives-ouvertes.fr/hal-02541754/document G
El 13 feb 2021, a las 9:46, Tim Mackinnon <tim@testit.works> escribió:
I never thought of that implication - if ivars are proper objects (is that now applied?) would this issue go away (an ivar would just get a new parent)?
This is a very interesting problem, as its a type of transaction, and I never though of it that way - its easy to think of it as just dumb code - but in effect it isnât.
Tim
On Fri, 12 Feb 2021, at 4:30 PM, Sean P. DeNigris wrote:
Wonderful to have progress on this important topic - thank you!
Sorry I haven't been following closely (maybe you addressed it already), but pushing up instance variables has a dangerous limitation - instances lose any data held in that var. I guess it's because it's deleted from the subclass prior to adding to the superclass to avoid duplicating. One solution would be to add a var to the superclass with a mangled name, copy the data for all instances, remove the var from the subclass, and then rename the mangled var.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
participants (4)
-
Evelyn Cusi Lopez -
Guillermo Polito -
Sean P. DeNigris -
Tim Mackinnon