You're right, it will be hard to provide compatibility at that point without doing an extensive/intensive work.
I think, at that change point we must provide as much back-compatibility as we can for the scripting, and that's all. And we must let use the scripting now, with a little warning about this for users. So they can know that the current interface isn't frozen yet. Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 14/03/2013, at 17:44, Wayne Stambaugh <[email protected]> wrote: > On 3/14/2013 11:45 AM, Miguel Angel Ajo Pelayo wrote: >> First and important: Encapsultion must go first, I'm not against it but the >> opposite. Read what follows for clarification: >> >> >> My concern is about the scripts that build functionality on kicad objects, >> scripts that people will build and >> should be maintained separately to KiCad. Now it's not important at all >> because the scripting base is tiny-0, >> when it grows, and we make changes to scriptable object interfaces, we will >> have to take care about this. >> >> So the earlier we encapsulate, the better. > > This is a work in progress. I think we are getting to the point where > there is not too much encapsulation work left. However, this is only > the first step in the process. One of the proposed changes is to create > a standard geometric model for all base objects in Pcbnew and Eeschema > which means there will likely be some substantial changes to the base > objects. Once the encapsulation work is complete, there should be an > effort made to clean up the some of the low object interfaces to make > them more coherent. > >> >> And in the future, if we change method names, we should (in the script side) >> provide some fallback/translation >> methods with deprecation warning. >> >> * Automated testing: >> >> , I think the scripting to-do should contain the making of a good bunch of >> test cases that cover all possible >> object operations that we are willing to support. I talked with Adam Wolf >> about that, it could be great >> to get them automatically checked on every commit, we can also extend this >> to check internal KiCad behaviors >> in an automated way :) >> >> >> * About build dependencies & swig: >> >> >> >> Compilation must always work, at this moment, cmake isn't able to fetch >> dependencies from .i files to .h files, >> or at least, I wasn't able to set it up. >> >> In my case I just remove the pcbnew_wrapper.cpp and >> scripting/pcbnew_wrapper.cxx and called >> make again, so it compiled gracefully. >> >> Getting dependencies for that automatically would be highly desired, and >> must be in my todo list at any point. >> >> >> >> >> >> >> Miguel Angel Ajo >> http://www.nbee.es >> +34911407752 >> skype: ajoajoajo >> >> On 14/03/2013, at 16:37, Wayne Stambaugh <[email protected]> wrote: >> >>> On 3/14/2013 11:07 AM, Miguel Angel Ajo Pelayo wrote: >>>> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/revision/4001 >>>> >>>> Hehe, nice cleanup, it's something that must be done. >>>> >>>> Anyway, interface changes to core objects, should be tracked carefully >>>> once we have scripting published, >>>> a change like this could break scripts working on the field: >>>> >>>> 151 >>>> >>>> void SetPos( const wxPoint& aPoint ) { m_Pos = aPoint; } >>>> 152 >>>> >>>> const wxPoint GetPos() const { return m_Pos; } >>>> >>>> 174 >>>> void SetPosition( const wxPoint& aPoint ) { m_Pos = aPoint; } >>>> >>>> 175 >>>> const wxPoint GetPosition() const { return m_Pos; } >>>> >>>> >>>> My opinion is, these changes need to be done, the cleaner, the better, >>>> but once scripting is widely deployed, >>>> we must provide some (scripting side wrappers) for compatibility, for >>>> example redirecting SetPos to SetPosition on scripting, >>>> and sending an "deprecated" warning for some set of releases. >>> >>> Sorry about that. I forgot rebuild the Python scripting support to see >>> if I broke anything. I'm still getting used to the idea that it is now >>> part of KiCad. >>> >>> Doesn't this kind of code automatically get updated the next time the >>> scripting code is reSWIGged or is this something that has to be hand >>> tweaked every time? I am familiar with SWIG so if need be, I will fix >>> the SWIG stuff from now on. I'm thinking the python scripting is going >>> to have to closely track the compiled KiCad code for the foreseeable >>> future. The will be a great of upheaval with the forthcoming footprint >>> library table stuff. The last thing I want to do is stop the >>> encapsulation work just to support Python scripting. >>> >>>> >>>> >>>> >>>> >>>> Miguel Angel Ajo >>>> http://www.nbee.es >>>> +34911407752 >>>> skype: ajoajoajo >>>> >>> >> >> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
