Smalltalk › Pharo › Pharo Smalltalk Developers

[BUG]: Pharo 4.0: Pull Up Inst Var Loses Data

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Sean P. DeNigris

[BUG]: Pharo 4.0: Pull Up Inst Var Loses Data

Administrator

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

Peter Uhnak

Re: [BUG]: Pharo 4.0: Pull Up Inst Var Loses Data

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-not-work

On Thu, Aug 13, 2015 at 5:58 PM, Sean P. DeNigris <[hidden email]> 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.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Eliot Miranda-2

Re: [BUG]: Pharo 4.0: Pull Up Inst Var Loses Data

In reply to this post by Sean P. DeNigris

Hi Sean,

On Thu, Aug 13, 2015 at 8:58 AM, Sean P. DeNigris <[hidden email]> 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?

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

Eliot Miranda-2

Re: [BUG]: Pharo 4.0: Pull Up Inst Var Loses Data

In reply to this post by Sean P. DeNigris

Hi Sean,

let me try again without the spelling errors...

On Thu, Aug 13, 2015 at 8:58 AM, Sean P. DeNigris <[hidden email]> 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.

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

stepharo

Re: [BUG]: Pharo 4.0: Pull Up Inst Var Loses Data

In reply to this post by Sean P. DeNigris

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.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>
>