[BUG]: Pharo 4.0: Pull Up Inst Var Loses Data
This is a nasty one. If you pull up an inst var via Nautilus menus, any data in that variable is nil-ed out in all instances. Ouch, not fun :/ Anyone else experience this? Same on 5.0? ----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Pharo-4-0-Pull-Up-Inst-Var-Loses-Data-tp4842592.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
There's open bug issue for class vars, maybe it's related? https://pharo.fogbugz.com/f/cases/15504/Pull-up-down-a-class-variable-does-n... On Thu, Aug 13, 2015 at 5:58 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
This is a nasty one. If you pull up an inst var via Nautilus menus, any data in that variable is nil-ed out in all instances. Ouch, not fun :/ Anyone else experience this? Same on 5.0?
----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Pharo-4-0-Pull-Up-Inst-Var-Loses-Data-tp4842592.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Sean, On Thu, Aug 13, 2015 at 8:58 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
This is a nasty one. If you pull up an inst var via Nautilus menus, any data in that variable is nil-ed out in all instances. Ouch, not fun :/ Anyone else experience this? Same on 5.0?
This is a bug in as many refactoring implementations as I'm aware of. Essentially pull up ivar and push down ivar are decomposed into separate class modifications, and with this approach, without some effort taken at a higher level, ivar state is going to get lost. The observation is that with pull up and pull down affected instances don't need to be become, simply some of their instance variables may need to be permuted. For example if we have C (ivx) with subclasses SCA (ivy) SCB (ivz) and we pull up ivy to get C (ivx ivy) and SCA () and SCB (ivz) then instances of SCA don't need to be changed at all, and instances of SCB change from (ivx,ivz) to (ivx,ivy,ivz). But if we have C (ivi) with subclasses SCA (ivj ivk) SCB (ivl ivm) and we pull up ivk then instances of SCA change from (ivi,ivj,ivk) to (ivi,ivk,ivj). I think I'm right in thinking that in all cases the refactoring can be done by modifying classes *without* doing a become on general instances of the class from which the iv is pulled up; instead all that may be needed is a permute. The situation is analogous on push down, but even simpler. No instances change side; all that may happen is that ivars may need to be permuted if there is more than one ivar in the class from which the ivar is pushed down, and that ivar is not the last in the class definition. -----
Cheers, Sean
_,,,^..^,,,_ best, Eliot
Hi Sean, let me try again without the spelling errors... On Thu, Aug 13, 2015 at 8:58 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
This is a nasty one. If you pull up an inst var via Nautilus menus, any data in that variable is nil-ed out in all instances. Ouch, not fun :/ Anyone else experience this? Same on 5.0?
This is a bug in as many refactoring implementations as I'm aware of. Essentially pull up ivar and push down ivar are decomposed into separate class modifications, and with this approach, without some effort taken at a higher level, ivar state is going to get lost. I saw this in VisualWorks 10 years ago. I guess it bites so infrequently and is tricky enough that it's never been fixed. But looking at the problem it may not be that hard. My observation is that with pull up and pull down, affected instances don't need to be becomed, simply some of their instance variables may need to be permuted. For example if we have C (ivx) with subclasses SCA (ivy) SCB (ivz) and we pull up ivy to get C (ivx ivy) and SCA () and SCB (ivz) then instances of SCA don't need to be changed at all, and instances of SCB change from (ivx,ivz) to (ivx,ivy,ivz) with all ivy bound to nil. But if we have C (ivi) with subclasses SCA (ivj ivk) SCB (ivl ivm) and we pull up ivk then instances of SCA change from (ivi,ivj,ivk) to (ivi,ivk,ivj); in become needed but the values of the second and third ivars need to be exchanged in general instances (*) of SCA. I think I'm right in thinking that in all cases the refactoring can be done by modifying classes *without* doing a become on general instances of the class from which the iv is pulled up; instead all that may be needed is a permute. The situation is analogous on push down, but even simpler. No instances change size; all that may happen is that ivars may need to be permuted if there is more than one ivar in the class from which the ivar is pushed down, and that ivar is not the last in the class definition. (*) a general instance of C is an instance of C or any of C's subclasses. HTH Cheers,
Sean
_,,,^..^,,,_ best, Eliot
Sean we got some problems with RB (once we spent a full day) because it seems that there is a problem is the code model. we got problems with pulling up several ivs. We will have to come back to it but we want to finish (deprecation of pluggableTextMorph and bootstrap dependencies). Stef Le 13/8/15 17:58, Sean P. DeNigris a écrit :
This is a nasty one. If you pull up an inst var via Nautilus menus, any data in that variable is nil-ed out in all instances. Ouch, not fun :/ Anyone else experience this? Same on 5.0?
----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Pharo-4-0-Pull-Up-Inst-Var-Loses-Data-tp4842592.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (4)
-
Eliot Miranda -
Peter Uhnák -
Sean P. DeNigris -
stepharo