[Glass] Grrrr cannot migrate (class rename with subclasses and with a name of a deleted class)

[Otto Behrens via Glass]

Hi,

I would consider doing it in 2 steps. We normally rename one of the
classes first and then deploy. In the next week's deployment cycle, we
do the other half. That way we are sure that all references are fixed
up correctly and that all instances are migrated.

Did not know about the changeNameTo: trick though. Not sure how I
would use it because Monticello will not necessarily pick up a change
and recompile.

In our system we really battled with references not being recompiled
and with strange behaviour in Pharo when loading code using Metacello.
And we really should try to find the problem, but we already spent way
too much time on this.

This may help you when using changeNameTo:, so, this is what we do
every time after loading code with Metacello:

| gofer |
gofer := Gofer it.
gofer disablePackageCache.
gofer repository: self localWonkaCodeRepository.
allPackageNames doWithIndex: [ :packageName :index |
  (MCWorkingCopy registry values anySatisfy: [ :workingCopy |
workingCopy package name asSymbol == packageName asSymbol ])
    ifTrue: [ gofer package: packageName ] ].
gofer load

Where allPackageNames is:
((MetacelloMCVersionSpecLoader on: <config class> latestVersion spec)
required: {aGroupName};
resolvePackageNames;
packages) values

HTH

On Thu, Aug 27, 2015 at 2:57 AM, Mariano Martinez Peck via Glass
<glass at lists.gemtalksystems.com> wrote:
>
>
> On Wed, Aug 26, 2015 at 8:51 PM, Martin McClure
> <martin.mcclure at gemtalksystems.com> wrote:
>>
>> On 08/26/2015 04:39 PM, Mariano Martinez Peck wrote:
>> > I am very very glad I asked. Thank you very much guys. Cannot believe so
>> > simply it actually was.
>> > So..to my defense, I didn't know a class rename was possible without
>> > going with the migration code :)
>>
>> This simplicity is not really very obvious.
>>
>> And it's not *quite* as simple as we indicated. You should also check
>> for code references to the class name, and edit those methods as needed.
>> If a method references "FaSecurityClosingPriceRecord2" it's going to
>> fail the next time you need to recompile it after changing the name of
>> the class, and if it references "FaSecurityClosingPriceRecord" and was
>> compiled before you made the change it still references the class you
>> deleted.
>>
>
>
> mmmmm I am wondering about the "and if it references
> "FaSecurityClosingPriceRecord" and was compiled before you made the change
> it still references the class you deleted."
>
> From Pharo, I did the refactor and so all methods were correctly updated
> (those that refer to FaSecurityClosingPriceRecord2 now refer to
> FaSecurityClosingPriceRecord2). So I assume that when loading with MC these
> latest code (after having run the above rename code), those methods that
> changed will be compiled correctly to the new class. Can you confirm this
> please?
>
> Now what happens if I already have methods who refer to
> FaSecurityClosingPriceRecord instead of FaSecurityClosingPriceRecord2. Those
> will refer to the old class unless compiled again as Martin says. I do have
> none. But still I am curious. What I do not remember is if MC would
> recompile all methods of the package or only those that changed. I think all
> of them. So...if I re-load the whole app I THINK all methods will be
> recompiled and hence all pointing to the new class (even if they refer to
> FaSecurityClosingPriceRecord class before the rename). Do you agree as well?
>
> Thanks in advance!!
>
>
>>
>> The reason that a class rename is relatively simple is that a class
>> doesn't use its name for anything important at runtime. The only reason
>> that I know of for a class to know its own name is so it can put in a
>> print string for debugging.
>>
>> At compile time, the compiler finds a class by looking up its name in
>> the symbol dictionaries, so in order to compile references to a class
>> you need the dictionary entry. Class names don't really do much more
>> than that -- the instances don't usually care.
>>
>>
>> Of course if you change instance variables, or the superclass hierarchy,
>> then the instances are usually affected and you still must do a migration.
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>