[Ktechlab-devel] More on Document / Simulator interface

[Julian Bäume]

On Monday 04 January 2010 23:50:19 P Zoltan wrote:
>   Considering the other discussions on this thread, there are two
> possibilities:
>   - make the simulator depend on QT, and use qreal
>   - use double
> 
>   It's a question of potential reuse: should or not that code depend on
> QT's types? If we want to use QT, then we should take full advantage of it.
I'm not sure about this. There are critics out there, that demonise the 
introduction of library-specific types. Okay, Qt offers them, so we might use 
them. But I don't know about the impact, this might have.
 
> > Why is IPin::isLogicPin() needed? Such methods raise some alarm bells in
> > my
> > brain, because they are mostly needed to fix bad design. Same question
> > for
> > IElectronicModel::isNonLinear() and IElectronicModel::isReactive(). May
> > be, we
> > need these methods, I just want to make sure.
> 
>   The issue here is optimisation of the simulator. There are different
> levels of needed computational power in order to simulate the circuits:
> 
> [...]
> 
>   My goal with those methods was to allow major simulator optimisations. If
> you have better idea on simulation, please tell.
Okay, I see. So this is an issue of _our_ simulator. IMHO there must be 
another way to tell the simulator about the type. This has nothing to do with 
the graphical representation of the circuit (and its simulated values), right? 
So this shouldn't be in the API.

>   My goal with those methods was to keep the implementation idiot-proof and
> list implementation independent. If we want to use lists, what kind of
> lists? std::vector, or something from QT?
>   Also here is the tradeoff:
> - if we allow access to those internal lists, a code like:
> "myDoc.wires().clear()" would be disastorous
> - other one is easier to read
> - another problem: if the document internally modifies its structires, and
> doesn't inform the simulator yet, the simulator might crash, if, for
> instance, a wire is removed from that list, and the simulator is trying to
> access it.
Okay, I got your point. May be, you are right and we should provide these 
methods.

>   I'd say it's better to separate the internal state; we can still return a
> newly created list, which is a copy of our list, but then what kind of
> list should we return? QT vs std
The classes/interfaces, we are talking about should stick to Qt types. Since 
the front-end is Qt-based, I don't see, why we should use something else.

> > May be, we should move this API discussion to git, soon. This way, we can
> > track changes and express our changes and thoughts in form of patches. I
> > agree, that sf.net doesn't provide the best front-ends for git to do
> > code-
> > review. I hope, I can come up with a better solution, soon. We could use
> > trac
> > hosted by sf.net, but I think, trac's git support is still somewhat poor.
>   On trac wiki there are also versions. This code was just conceptual. I'll
> upload (not in this week, probabily...) to git some code that compiles, .
Since these are just header files (almost), there is no need to compile ;) We 
just have to make sure, the project, as a whole, compiles. (Also, I agree, 
that we shouldn't have any garbage in the tree. But, I think, it's fine to have 
something "work in progress")

bye then
julian