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

Eliot Miranda eliot.miranda at gmail.com
Thu Aug 13 17:23:15 UTC 2015

Hi Sean,

On Thu, Aug 13, 2015 at 8:58 AM, Sean P. DeNigris <sean at clipperadams.com>

> 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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150813/66481f96/attachment.htm

More information about the Squeak-dev mailing list