We will get there :) Stef
On 29 Jan 2014, at 15:36, Pavel Krivanek <[email protected]> wrote: > > > > 2014-01-29 Hilaire Fernandes <[email protected]> > Le 28/01/2014 18:41, Pharo4Stef a écrit : > > this is years since I clean Morphic (may be I’m that good at it) but this > > is important to > > go step by step. So I would really like to get a list of simple actions. > > Do you have an idea? > > > What about a brutal scheme, independent of all code quality considerations: > > - dedicate a Pharo release process *only* to Morphic cleaning so people > will know it gona be brutal > - mark as deprecated all morphic methods unsused in the system. When a > client (like me with DrGeo), use some of the deprecated method, fill a > bug ticket, then discussion should arise about what to do: > i. unmark it as deprecated > ii. move it in external package > iii. adoption by the client in its application code > - do the same with unused classes from the Morph hierarchy. > > > I guess Steph already did some of this in the past. > > The idea is you don't want to refactor unused code, right? > > I would like to continue in the direction started with the Morphic-Core. It's > a subset of Morphic that is able to be loaded into a headless image, > initialize itself and show world with one basic responsive morph. > We can clean it and continue with basic fonts support, windows support etc. > Every step will produce one package that can be loaded on top others, will > heave well defined dependencies, will be small in size, easier to understand, > maintain and refactor. > It looks hard but in fact it is not so horrible. In one of my previous > testing image I was able to reach the state where Morphic-Core was clear - > generated no new unimplemented classes and similar mess. > We only need to define it as a common goal. > > Cheers, > -- Pavel > > > > -- > Dr. Geo http://drgeo.eu > > >
