kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/09/2012 04:12 PM, Miguel Angel Ajo Pelayo wrote:
> 2012/8/9 Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>:
>> On Thu, Aug 09, 2012 at 11:53:42AM -0500, Dick Hollenbeck wrote:
>> Then a facade between python and wx would be the best; also it would be
>> an 'insulation layer' from C++ specific stuff, providing context and
>> translation (for example 'hiding' the whole BIU stuff and omitting
>> internal-only interfaces).
> I thought about that, but then on what kind of measurements? mm, or inches? ,
> we could add extension methods to wxPoint and wxSize to allow
> conversion from/to measurements, now we have FromMM(xx)  ToMM(xx) ,
> etc.
>
>> As an example: do you *really* want to expose to the python users
>> functions like EnsureTextCtrlWidth, ProcessExecute or the drawing
>> functions?
> Well, that's was really weighted when we started the scripting
> implementation, we could "clone" all our exposed classes interfaces in
> the .i files, or we could just suck up all the header files of any
> interest to us.
>
> This way we:
>
>    * Save an awful amount of man/hours.
>    * The moment a class is updated in the .h with new (public) methods
> it gets updated on the python side at compilation time, no human
> rework needed.
>
> But:
>
>    * We cannot manually document (with pydoc style) the classes and methods.
>    * We expose things we wouldn't like too
>
> Anyway, this last unwanted "feature" could be avoided with the use of
> "ignore" clauses into the .i swig files, that could make a lot of
> sense.
>
> Also we have the #ifdef SWIG that Dick told us about
>
>> IMHO python classes should be tinked about and defined separately... It
>> doesn't seem a good idea to expose the innards of pcbnew in this way, to
>> me...
> If we did it that way, we wouldn't have scripting now (I think)
> because it's a ton of work, even more when I'm still learning about
> KiCAD internals, which is huge!! :)
>
> The day we have time enough, if we find the benefit interesting enough
> we could do it just rewriting the .i files (I think it's the only
> change we might need), but , it would be a long term maintenance cost
> (compared to the drawbacks of over-exposing).


What we're seeing here is the importance of actually engineering good C++ interfaces.   

This is actually vitally important to the project.  Remember BOARD_ACTIONS?

Because some existing C++ interfaces are good and some existing C++ interfaces are bad, no
blanket statement is possible.  Let's expose the good ones, and make the bad C++ ones good
before exposing them.  The closer the SWIG interfaces match the C++ interfaces, the less
work you have long term, and you can more easily pick up additional languages later if
wanted, such as scripting language ___________.