[Cuis-dev] Refactoring regressions
Phil B
pbpublist at gmail.com
Sat Mar 7 11:44:29 PST 2020
Regarding 2: perfect, thanks!
Regarding 1, the refactoring tools should not be changing anything (methods
or variables) they don't understand. To see the issue:
1) open a base image
2) install OMeta2Examples.pck.st from https://github.com/pbella/OMeta-Cuis
3) open a Message Names window
4) search for 'space'
5) right click on the 'Character class space' implementor
6) select 'refactorings...' then 'rename...'
7) give it a new name of something like spaceAAA
When the refactoring window comes up you should see both implementors and
senders of space in various OMeta subclasses. The problem with the
refactoring tools even attempting to refactor these methods is that the
code they are parsing at best may not be standard Smalltalk and at worst
may be something totally alien so the results of the refactor will often be
broken code. The problem is the same for variables.
In the case of OMeta, while the pretty printed code is valid Smalltalk,
it's also generated code that should not be edited so if the refactoring
tools say 'Oh, I know how to deal with this' it will overwrite the actual
source code. If it tries to refactor the actual source code, there's about
a 105% chance it will fail :-) Even if you tried to support OMeta syntax,
I or others could write our own parsers in OMeta which create a derivative
syntax which again would break the refactoring tools. The constant is that
in order to do this, they need to override #compilerClass. So that's why
I'm suggesting at a minimum, the implementors and senders in subclasses
with an unknown #compilerClass should be ignored/excluded. (if you want to
be extra safe, check both #compilerClass and #parserClass) A nice plus
would be some indication of any senders/implementors that are being ignored
so I know go back and check them manually.
On Thu, Mar 5, 2020 at 8:17 PM Hernan Wilkinson <
hernan.wilkinson at 10pines.com> wrote:
> Hi Phil!
> I just fixed the problem with removing senders when refactoring (error
> number 2) and uploaded to git.
> Please if you can check that it works would be great.
>
> About the 1), I look for that in the repo and I could not find what I did
> when you ask for that the first time... could you let me know again what
> are you expecting? And also, do you want that for all refactorings or only
> for a few? For example, do you want that behavior when renaming and
> instance variable or only when renaming a selector?
>
> Thanks!
> Hernan.
>
> PS: Getting slowly back in track :-)
>
> On Mon, Jan 27, 2020 at 4:33 AM Phil B via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> It looks like a couple of previously fixed issues are broken again as of
>> 4030 (not sure exactly what changeset(s) broke things, only that I ran into
>> these issues again now):
>>
>> 1) compilerClass doesn't look like it's being properly checked to
>> determine if classes/methods should be included in the refactoring.
>>
>> 2) Removals get lost if sender methods are removed in the refactoring
>> window and then you switch to implementors view, then back to senders.
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>
>
> --
>
> *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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200307/2f660897/attachment.htm>
More information about the Cuis-dev
mailing list