w > > 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
This is not that easy. Because we should really learn about morph internals. And this what we were planning to do with fernando but he left. and we had to reorganise. stef > - 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 > > >
