[Cuis-dev] Method Refactorings on Method Set Window List

[Gerald Klix]

On 12/10/24 3:47 PM, Juan Vuletich via Cuis-dev wrote:
> On 12/2/2024 10:54 PM, Ulises Lopez Pacholczak via Cuis-dev wrote:
>> Hello,
>>
>> I would like to propose the following changes to Cuis.
>>
>> Cuis refactorings are amazing, and it would be a great idea to have 
>> them available in more places. One interesting one is the Message Set 
>> Window (which is used by senders and implementors, for example). I 
>> added some refactoring methods to the right-click menu of this window 
>> ("rename...", "change keyword order...", "add parameter...", "remove 
>> parameter...", "inline method...").
>>
>> I did it by creating a superclass of BrowserClass called 
>> "MethodRefactorProvider", which is a provider of different Method 
>> Refactoring methods so that they can be used in more places than the 
>> browser. I pushed up the corresponding methods of this refactorings, 
>> so there is not repeated code.
>>
>> Although it is a nice addition to Cuis, I wasn't able to add "move to 
>> instance/class method", "push up", "add in superclass as 
>> subclassResponsability", "push down to subclasses" or "push down to 
>> one subclass" as they require to recalculate the "senders" or 
>> "implementors".
>>
>> I wasn't able to do that, because Method Set Window is created with 
>> the list of elements that should be shown in the Message List. That 
>> is why I wanted to ask the community if it made sense to modify the 
>> model in order to be able to support this other refactors. In my 
>> opinion, it only makes sense to have the first four refactors on this 
>> window as they are the only ones that are useful without looking at 
>> the hierachy (I wouldn't include "inline method" although I made it 
>> work).
>>
>> I leave my changes, so, if you consider, they can be included to the 
>> Dev image. I can remove the "inline method" if you would like to.
>> Thank you,
>> Ulises
>
> Hi Ulises,
>
> This is interesting and well done. Still I don't think the extra 
> complexity is worth it. Evolving the system while bounding complexity 
> is always a balancing act. This time the scale leans towards simplicity.
>
> Thanks,
>
>
Hi Ulises,

I suggest to move these methods to a package.
I hope that they won't modify to many methods
already present in the standard image. That
will make package maintenance much easier.


Best Regards,

Gerald