[Ktechlab-devel] Yet another draft of the interface code

[P Zoltan]

On Sat, 09 Jan 2010 00:35:19 +0100, Julian Bäume <julian at 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.