On Sat, 09 Jan 2010 00:35:19 +0100, Julian Bäume <jul...@svg4all.de> wrote:
> On Thursday 07 January 2010 22:12:40 Alan Grimes wrote: >> =( >> I spend 4 years tweaking this code. >> >> And just as it's just starting to get under control... >> >> You go off half-cocked and start designing these silly little >> interfaces... > Nobody wants to make your work obsolete, here! I haven't touched any of > the > parts, you are working on, yet. The last days, I have been merging all > your > changes from svn into git to work on the integration of the simulator. I > have > to little knowledge about how the simulator works, to touch it. I won't > change > anything in there, without talking about it on the list and get your ACK > on > it. > Integrating the simulator as is now to a new GUI code looks tough to me. It's definitely a lot of work, and a lot of regression hunting. If you think that's the way to go, it's ok for me. Maybe I should start creating a tests for ktechlab. That way if something goes wrong, we could see it immediatly. But in order to create tests, we should have a definition of how something _should_ work. Tests that come to my mind: - totally automated: - matrix solver: it's math, obvious to test - testbench for some classes, send messages to them and see how they respond - create a gui-less document + simulator, load a circuit, run it for a given time, capture the waveforms and compare them to reference waveforms. The sum of differences define if the test is passed or not - interactive tests: - very small programs that shoud 1 component / something on the screen, and send / get messsages, print them. useful for GUI. >> The interface is the header file. > That's only part of it. For a good plugin-system to work, we need to > agree on > these header files. There need to be some header files (interfaces) that > are in > a shape, where they can be exported to the public. (This is the API). > This API > should be as clean as possible and as direct as possible. This is hard > work > and as far as I know KTechLab's code-base, most header files aren't > ready to be > a public interface. If the classes are for internal use only, this is > not as > important and it might be okay to have some "dirty" object-oriented > design to > make things more efficient, but it should look "good" from the outside > world. > For useful external API, some document level functionality should be exposed. The interfaces I've linked here should be mostly internal. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
