[Cuis-dev] Rename class not logging to user changes

[Eric Brandwein]

If the rename was written in the ChangeList as the sequence of adding all
methods to the new class and then removing the old class, then, if the
class to rename had more methods than when the rename was logged, those
methods would be lost. On the other hand, if there was only one entry for
the rename, all those methods would be preserved. I personally prefer the
latter, because that's what I think I'm doing when applying a class rename.
The downside of this would be that you can't choose to put some methods in
the new class and some in the old one when applying the ChangeList
partially.

About the references renaming, I would make that a single change too,
following the idea above, but separated from the class rename, in case you
want to apply the class rename and then provide a class for the old name.
The downside of this, again, would be that one can't select just some
references to be renamed.

I guess it's a matter of flexibility of automatic application in different
images versus flexibility of manual application. Maybe asking the user
which one they prefer would solve it, and maybe taking one of the
approaches as default when applying it automatically without having to ask
them would help in making image recovery a more streamlined experience.

Anyways, I'll try to implement which seems the simplest approach and then
see about the other stuff.

Cheers,
Eric


El vie., 5 jul. 2019 12:35, Hernan Wilkinson via Cuis-dev <
cuis-dev at lists.cuis.st> escribió:

> recording the whole sequence is going to be more difficult because that it
> is not what really happens... so those events should be "artificially"
> created, and I think that for an automatic recovery of the image that is
> the most used case for this, it is better just to add the "rename" event.
> When recovering it will just rename the class and then apply the method
> changes...
>
> On Fri, Jul 5, 2019 at 12:20 PM Juan Vuletich <juan at jvuletich.org> wrote:
>
>> Maybe they should be recorded both ways: as ClassRename and as sequence
>> {ClassCreation. NewMethods. UpdateClassReferences. OldClassRemoval}. There
>> are some reasons for wanting the sequence. One is to be able to re-apply
>> changes, or not require to be in exactly the same state as when the change
>> was created.
>>
>> If both ways are included, then the user of the file can decide what
>> s(he) prefers.
>>
>> On 7/5/2019 10:11 AM, Hernan Wilkinson via Cuis-dev wrote:
>>
>> Hi Eric,
>>  yeap, class rename is not being logged ... a new type of change should
>> be created for that. If fact, it would be great to record all type of
>> refactorings as refactorings instead of only the changes composed by the
>> refactoring.
>>
>>  Regarding the new change record, it should be a class rename type, not a
>> deletion and creation of the new one because that does not happen when
>> doing a class rename.
>>  There is an important question to answer: when loading the change
>> record, should it rename the references too or should only do it for those
>> that are recorded? ... if all the changes are loaded then the later should
>> be applied but if not? I think the best option is to only rename the class
>> and then let the other changes change the reference. (I hope this is
>> understandable :-) )
>>
>> Hernan.
>>
>> On Fri, Jul 5, 2019 at 2:04 AM Eric Brandwein via Cuis-dev <
>> cuis-dev at lists.cuis.st> wrote:
>>
>>> Hi all,
>>>
>>> Today Cuis broke because I was messing with Morphs, and I had to close
>>> the image. Unfortunately, I hadn't saved my changes, so to recover them I
>>> had to rely on the .user.changes file. I opened up the image again, and it
>>> asked me to recover changes. I selected to automatically recover them, and
>>> a strange error occurred: it told me that UndefinedObject didn't understand
>>> #removeSelector:. Digging through the ChangeList, I noticed something: the
>>> class renames were nowhere to be seen. So, what was happening is that there
>>> were some ChangeListElements that removed selectors from classes that
>>> didn't exist because they had the old names from before I renamed them.
>>>
>>> All this story is to point out that bug: the class rename isn't logging
>>> to the changes file. And I'm not really sure how to solve it quickly and
>>> cleanly; there isn't a ClassRenameChangeRecord class like there's a
>>> ClassDeletionChangeRecord, so either there should be a new kind of
>>> ChangeList record to log class renames or we should log the deletion of the
>>> class and the subsequent adding of all the methods that were previously in
>>> that class to the class with the new name. What do you think?
>>>
>>> Cheers,
>>> Eric
>>> --
>>> Cuis-dev mailing list
>>> Cuis-dev at lists.cuis.st
>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>
>>
>>
>> --
>>
>> *Hernán Wilkinson Agile Software Development, Teaching & Coaching*
>> *Phone: +54-011*-4893-2057
>> *Twitter: @HernanWilkinson*
>> *site: http://www.10Pines.com <http://www.10pines.com/>*
>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>
>>
>>
>> --
>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
>> @JuanVuletich
>>
>>
>
> --
>
> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
> *Phone: +54-011*-4893-2057
> *Twitter: @HernanWilkinson*
> *site: http://www.10Pines.com <http://www.10pines.com/>*
> Address: Alem 896, Floor 6, Buenos Aires, Argentina
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190705/daff0935/attachment-0001.htm>