[Bf-python] CurNurb/IpoCurve/BezTriple hackery

[Ken Hughes]

Joseph Gilbert wrote:
> I'll leave implementation to people who know this better (stivs, 
> willian, you, etc.) but It seems that the way to resolve this - is to 
> wrap this data when its returned.instead of just a py_list returned. One 
> possible way of doing this would be to have IpoCurve store a py_list[] 
> and periodically update it with pointers to bez_triples when neccessary 
> and only return a pointer to this list to the user. (might work ;o)

So, if I understand what you're saying, the IpoCurve object maintains
its own list of BPy BezTriple objects which don't actually wrap the
Blender BezTriple?  So when the IpoCurve object is deallocated, the
deallocation procedure would then propagate the values from the
BPy BezTriples to Blender's BezTriples?  We could also include a
"dirty" flag into each BPy BezTriple to indicate which objects had
been modified and only copy their info back.  And the BPy BezTriple
objects are only created upon request.

I had a similar idea; the IpoCurve wrapper has a pointer to a list
of BezTriple wrappers and each BezTriple has a pointer to its "parent"
IpoCurve wrapper.
   (1) if the IpoCurve changes (addition or deletion), it goes through
       its list of BezTriple "children" and updates their pointers
   (2) when a BezTriple is deleted (the Python reference count goes
       to 0), and its "parent" BPy object still exists, then the
       parent is notified so it can remove the chld from its list
       of wrappers.
If IpoCurve wrapper only builds the pointer list if its BezTriples
are accessed (for example, we call Ipocurve.getPoints()).

I think your idea is cleaner, at the cost of more memory (but unless
we have huge lists, not massive amounts).

Either way we go, we have to do the same thing with Ipos and
IpoCurves; otherwise

   a=Blender.Ipo.Get('ObIpo').getCurve('LocX')
   b=Blender.Ipo.Get('ObIpo').getCurve('LocX')

gives two different objects manipulating the same data and have the
same problems all over again.

Ken