On Sat, Mar 15, 2003 at 08:08:22PM -0800, Daniel Rogers wrote: > I have been working pretty hard to get a handle on all the changes that > need to be made in order to move gegl to the structure that you and I > have (mostly) agreed on. > > There are many changes that run deep into gegl. Changes that require > rethinking of several subsystems at the same time. At some point, it > become easier to start nearly from scratch. I think gegl has reached > that point. No, I dont think we need to do this. We have a good set of classes and unit tests and everything we want to do can be done by re-factoring things until we get them the way we want. This is why we have unit tests and how they are used. You can make pretty aggressive changes if you have a good set of unit tests, and we have those. I have made quite a few big changes since gegl has begun and it has not been necessary to start over. > > It was a mistake to not design tiling, caching, and threading into the > system from the start. Adding these systems require changes to nearly > every part of gegl. No. I dont agree. These things can all be made to fit with what we have. > It was also a mistake to assume that only one color model would exsist > in the tree at any one time. This also requires changes in many parts > of gegl. No one assumed this. It was always the intention to make sure that gegl could do automatic color conversions. I think this is what validate_inputs is all about. All kinds of data conversions could potentially happen at that stage. > Color conversion is a hard problem. Doing it right requires designing > the system for it. While some consideration in this direction was made. > There was a lack of research into the topic that caused the > considerations to be insufficient. My last point about only one color > model is an example of this. It is my belief that adding Color > conversion after the fact would require significant changes to gegl. > There are several significant changes to the class structure of gegl > that even you suggest is "the right idea." Changing the class structure > this much is equivlent to redesigning whole subsystems of gegl. > I do not think that gegl should be thrown out entirely. There are some > good ideas in there that can and should be salvaged. If fact I don't > really think of it as starting over per say, because you are not > starting from ground zero. There is a lot I have learned from gegl and > I think there is a lot I can continue to learn. It is just that I feel > that rewriting gegl from near-scratch would be easier than putting in > all the changes that need to be added after the fact. Gegl is a work in progress. If something needs to be done, let's figure out how to do it and how to refactor what we have to achieve that. This is in the spirit of test-driven software design. Refactor what you have, write lots of unit tests and keep them working at 100%. Strive to do "simplest possible thing that could work" at each stage. If your tests are strong, you will be able to re-factor and improve your design without breaking things. Im a big fan of that part of XP programming. Calvin
