kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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
>