2016-12-07 10:44 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>: > > 2016-12-06 19:29 GMT+01:00 John Brant <br...@refactoryworkers.com>: > >> > We could make it configurable. "Manually" accessors will be generated >> in simplified mode and related refactorings will use intelligent mode >> >> My personal preference would be to ask the user what to do when >> performing the accessor refactoring. If the class hierarchy already has a >> method with the name of the variable, we can look at that method and >> determine what to do. In the case of #name, we could see that it is defined >> in a superclass and ask if it is ok to override the method (likely a good >> choice, but not always so it is good to confirm with the user). If the >> class directly defines the method, and that method has a return that >> returns the variable, then we can ask if they want to use that method as >> the “accessor” even though it does some other stuff (and potential returns >> a different value). Finally, if some subclass defines the method, then we >> can ask if they want to create that method even though some subclass is >> overriding it. Of course, we could have any combination of all three too. >> If they want a different method, then we should ask what to name the method >> instead of appending a number to the name. > > > Ok. You prefer tons of questions to user just to perform stupid accessors > generation. And, please, don't say that it is rare cases. It is quite > common which nicely shown here 18880 > <https://pharo.fogbugz.com/f/cases/18880/Autogenerating-accessors-should-be-less-naive> > . > I wonder do you have *real* experience when it protected you from > destroying system? We only talk about simple accessors refactoring. >
Possible solution in inbox for case 18880. Needs a test case. As far as I can see, this change does not conflict with application of abstract-variable-refactoring, but needs some testing (exising RB-Tests are green).
