[Cuis-dev] Refactoring regressions

[Hernan Wilkinson]

Hi Phil!
 I just pushed a change that takes care of that.
 It compares compilerClass with Compiler and if it is different it does not
include the method in the implementors/senders. As you said, it is the
simplest solution. If other compilers are created that keep Smalltalk
syntax we will have to change this but that is unlikely to happen.
 I did this only for the change selector refactoring, that is rename, add
parameter and remove parameter because I think those are the ones that this
change was needed for... I don't see anybody doing a rename instance
variable in a class that is not a Smalltalk one.

 Let me know if it works as you expected!

 Cheers!
 Hernan.

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

> 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
>>>
>>

-- 

*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/35dc4f64/attachment.htm>