[Bf-python] Re: Python Ipocurve/CurNurb module changes

[Stephen Swaney]

On Tue, Jun 21, 2005 at 01:36:29PM -0700, Ken Hughes wrote:
> >* Control Points
> >
> >Having a BPoint class is probably not a bad thing.  So far, we have
> >simply used a list of floats.  This may be a place where we could
> >create a base ControlPoint class and derive BPoint and BezTriple from
> >it.
> 
> Can't get my head around this (what the base class would do); maybe
> if you can sketch this out more on the wiki later it will clarify.

Just thinking out loud here.  And suggesting a place where you could
play with actual class inheritance.  Both Nurbs and IpoCurves deal
with control points.  Right now, for ipocurves, only beztriples are
supported but there is a slot for nurb points already which imples to
me that someone was thinking about it

So far we have used a simple list of floats as a substitute for BPoint.

One reason for a BPoint type is that control points for nurb and
bezier curves would have similar semantics.


> >Since the control points are an attribute of a curve, we should change
> >the BezTriple impl. to hold a pointer to the parent curve and an index
> >into the control point array.  This way we can throw an exception when
> >the control point array has changed too radically.  I know this is not
> >a pythonic as we would like, but given that we are wrapping an array
> >contained in an object, I believe it is a reasonable compromise.  This
> >behavior will need to be explicitly documented.  This change affects
> >iterators.
> 
> My idea goes the other way; the curve hold pointers to its child bezTriple.
> Changes to the curve are propagated down to them; deletion of points is
> handled by NULLing the bezTriple's pointer.  Each bezTriple only has to
> check "if (!self->bezt)" to throw an exception.

The thing we are wrapping here is an array contained inside a blender
object, not an independent object.  If we were doing a clean
implementation, I would agree completely.


> >* Curve/Ipo
> >
> >...
> >
> >One thing on my list is to replace the string-lookup getattr code with
> >PyGetSetDef tables in tp_getset member of the py object struct.  The
> >string based attr stuff is legacy code from when that was the only way
> >to do it.  Time to get with the python type=>class migration.  I
> >started doing this for CurNurb.  I can check it in if you need an
> >example.
> 
> Yes, if you can check in what you have (or send me a copy to look at)
> it would help.  I was playing with these this morning and I'm not sure
> I'm happy with how I got it to work.  Depending on how far along you
> are (and if you want to), I can take this on (finishing the implementation
> in CurNurbs) as well.

I will get the CurNurb tp_getset stuff checked in.  Then you can go wild!


> Related note about Ipo vs Curve: you're thinking iterators, operator[],
> del/append/insert for Ipos (and Curves) also instead of Ipo.getCurve(),
> Ipo.addCurve()?  Hadn't thought for the next level up yet, but that
> makes a lot of sense.

Yep!  IMHO, we should do this for all our types that have
sequence-like data.


> 
> >* Thin Wrappers
> >
> >One of our basic bpy design principles is that the bpy types are
> >implemented as thin wrappers around blender data.  One reason for this
> >is not incurring the overhead of copying data unnecessarily.  A bigger
> >reason is that once you make copies, you are suddenly faced with all
> >the issues of a distributed database: keeping copies in sync, noticing
> >when the underlying data changes, race conditions on updating, etc.
> >Remember that blender Spaces are essentially independent browser/
> >editors accessing the data and that any Space can change it
> >asynchronously.
> 
> I was thinking about this, related to Python GUI scripts with callbacks.
> Is my thinking correct: a Python GUI which, for examples, messes with
> IPOs, shouldn't try to keep the IPO objects around between callbacks
> because they could be modified or deleted at any time in some other
> Space?  (I guess I could write a Python script to test this, but
> suspect I already know the answer).

Managing object lifetimes is critically important in OO programming.

> 
> >* Attribute access
> 
> I see this as a design decision for you guys to make (me being the
> grunt programmer for now :-) ).  I don't know that I would say
> directly accessing an attribute is "bottom-up":  i.e.,
> 
> myMat=Blender.Material.Get('Material')
> gives an instance of a Material, but there's nothing in the API (that
> I know of) I can use to find which objects are linked to myMat.  (Of
> course, this could be coded in Python if someone really wanted to know).

This is my point.  Blender has a network style database where you
navigate to an item of interest.  The natural way to get a mateial is,
for example.via object.obdata.matlist[n].  Material.Get() just gives
you a material without any sense of its relationship to anything else.

-- 
Stephen Swaney			
sswaney at centurytel.net
231-228-7370