2017-11-02 18:48 GMT+01:00 tim Rowledge <tim at rowledge.org>:

>
> > On 02-11-2017, at 10:38 AM, Bernhard Pieber <bernhard at pieber.com> wrote:
> >
> > Hi Eliot, Hi Marcel,
> >
> > IMO refactoring support is one of those features that belong to trunk. I
> am not suggesting that any one of you should do the work. I just want to
> find out what you and others think about this? Would any one object and if
> yes, why?
>
> I have a small objection, not specifically to the refactoring stuff but to
> the effect adding more facilities will have on the more general problem of
> giant menus and overfilled tables of hotkeys.
>
> Generally our menus are horribly poorly arranged. Some are hierarchical
> menus, some fake it badly with the “fooble…” entries that open another
> menu, or sometimes a different UI widget. The code side of menus is even
> worse with approximately 42 classes involved in making a once-simple menu
> concept.
>
> So whilst I’d like to see refactoring support included by default in the
> tools, let’s try to make use of that to refactor our really messy, untidy,
> badly in need of refactoring, UI framework(s)
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> If you don't pay the exorcist do you get repossessed?
>

IOW, what we need is a tool for understanding those legacy messy untidy
codes which is a preamble to applying any refactoring...
Something like a brain, but better than the poor one we have.
Precisely because we started to complexify that code once we lost the
overall picture of the problem/solution...
And we stopped modifying once it was humanely impossible to add a feature
without breaking two others.
Such code is a sort of local optimum...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171102/f6e80196/attachment.html>