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

[Mariano Martinez Peck via Glass]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150826/62a68c0d/attachment.html>