kicad-developers team mailing list archive

[LordBlick <lordblick@xxxxxxxxx>]

In response to a message written on 02.10.2014 01:26, from Wayne Stambaugh:
> On 10/1/2014 3:08 PM, jp charras wrote:
>> Le 01/10/2014 20:42, Daniel Dawid Majewski a écrit :
>>> On 01.10.2014 16:25, Wayne Stambaugh wrote:
>>>> They do.  It is automatically generated by the compiler just like the
>>>> source code comment explains.  Unless you need some special copy
>>>> semantics (not just a direct copy of every class member which is what
>>>> the compiler will generate), you do not need to write your own copy
>>>> constructor.
>>> Ok, so where are nested following python methods ?:
>>> Copy(MODULE self, MODULE src)
>>> Copy(ZONE_CONTAINER self, ZONE_CONTAINER src)
>>> How I could make ?:
>>> Copy(TRACK self, TRACK src)
>>> Copy(VIA self, VIA src)
>>
>> Seems there is a mistake between a copy constructor and the Copy method
>> which exists for some BOARD_ITEMS, but not all (because currently this
>> method is not needed in C++ Kicad code for track/vias)
>>
>> The Copy method copy only some values from an existing source to an
>> existing target.
>>
>> The default copy constructor creates a clone (a new item) of an item.
>> This is very different.
>>
>> I'll add a Copy method (mainly for python scripts) for tracks/vias soon.
> 
> Please don't unless there is no other solution.  There is no reason to
> create a custom copy method when the default copy constructor is more
> reliable.  I promise you someone will add another class member that they
> will forget to add to the copy method.  We've been bit by this several
> times in the past.  It's a poor design pattern that I do not want to
> repeat.  The only time I can think of the use a custom copy constructor
> is when dynamically allocated memory is involved.  Are we using copyctor
> feature flag in SWIG when generating the C++ source files?  If not, then
> an explicit copy constructor must be defined.  You can read about it
> here http://www.swig.org/Doc1.3/SWIGPlus.html#SWIGPlus_nn7.  Let see if
> we can get SWIG to do it for us before we travel down the bad design path.
IMHO JP Charas is not going to do with any coping class. That's misunderstanding.
I suggest to rename all python „Copy” methods to „paramCopy”(or sth similar),
cause in fact they are only coping values of elements between instances of same
class.
Python formula „newItem = Item.__class__(pcb)” makes new instance of the same
class, so we no need class copy or sth similar…
Apart from this, we have python method „Clone”, which seems unusable - returns
some bogus instance of pcbnew.EDA_ITEM. It's possible to make it workable by
overloading method with creating new instance of the same class
[Item.__class__(pcb)] and then coping values from old to new instance.

-- 
Best Regards,
LordBlick