[Cuis-dev] Refactoring regressions

Phil B pbpublist at gmail.com
Sat Mar 7 11:58:29 PST 2020


I forgot to mention:  ideally this would be done in a flexible manner.  So
rather than hard coding Compiler in the tools, have a method that returns a
list of valid #compilerClass values so if anyone uses an alternate compiler
for Smalltalk code, that they would be able to include it in refactoring.
Alternately, we could use a blacklist approach where the tools accept
anything *except* a list of #compilerClass values to exclude.  I think a
whitelist approach makes more sense since it seems like every time I've
overridden #compilerClass I've done it at least in part because I've
tweaked the syntax in some way.

On Sat, Mar 7, 2020 at 2:44 PM Phil B <pbpublist at gmail.com> wrote:

> 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/c9311927/attachment-0001.htm>


More information about the Cuis-dev mailing list