[Bf-python] FW: [Bf-blender-cvs] CVS commit: blender/source/blender/python/api2_2xObject.c

[Stephen Swaney]

On Thu, Nov 03, 2005 at 07:39:05AM -0800, Ken Hughes wrote:

> It's not just here, it's in a number of places.  For example, NMesh, 
> Mesh and Object deal with a list of materials instead of a sequence 
> operator; the individual Material objects are wrapped but the list 
> isn't.  So to assign new materials, you have to assign the whole list, 
> not just a single material:
> 
>    matlist = obj.materials
>    obj.materials = [matlist[0],matlist[1],mat2]
> 
> instead of
>    obj.materials[2]=mat2
> 
> The problem is we would also need to implement a bunch of new sequence 
> operators for these types, and there may not be any guarantee that the 
> way Blender internally represents one type is the same as another (could 
> use array in one case, linked list in another).

I've been thinking about this since we started the tp_getset stuff.
A lot of our bpy types - which are slowly becoming classes - have
a list as a member attribute.  Ideally, we would like to script something
like 
  obj.materials[2]=mat2

So far, the best solution I have is to create little helper classes
like a MaterialList with their own sequence operators.  These helper
classes would enforce their own constraints like list length or 
element type.

As for Blender's internal representation, from an interface point of
view, I don't think we need to be limited by whether the underlying
data is an array or linked list, for example.  Think of the Bpy API is
like a giant Adaptor Class in the Design Patterns sense.  Our goal is to
present a consistent, orthogonal interface for the user no matter what 
the underlying data looks like.

-- 
Stephen Swaney
sswaney at centurytel.net