On 08/09/2012 04:12 PM, Miguel Angel Ajo Pelayo wrote: > 2012/8/9 Lorenzo Marcantonio <[email protected]>: >> 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 ___________. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
