[Bf-python] Bone module simplification

[Yann Vernier]

On Tue, Jan 04, 2005 at 11:22:48AM -0500, Gilbert, Joseph wrote:
> The major item here is the way the Bone module is being implemented. You
> have changed this module to wrap C-created object immediately instead of
> making a python representation that is 'created' later.  
Yes, in particular since the module already had a wrapper mode.

> Basically this module was modeled on the way that NMesh created objects.
> All python objects are not physically created until they are 'updated'.
> When you create a 'Bone' for instance - it is only being created as a
> python representation of a 'Bone'. Upon a call to Add_Bone() (or another
> function where the bone must be used by the blender application) the
> Bone module would only then create a C-representation of the Python
> object.
Except the code did not wait for those updates. There were update
functions for both directions, but the actual access functions used the
Bone structure if there was one, ignoring the related BPy_Bone fields.

> This way all python objects reside in python and when a script exits -
> python cleans up the mess (for bones that were nonsense). If you make
> the Bone class a wrapper for C objects directly people may not use them
> (maybe only as temporary objects) and they will occupy memory until
> Blender exits - since datastructs in blender are not 'freed' till exit()
> is called. 
Does this really apply to the whole guardedalloc library? I thought this
was how the ID system worked, which is reference counted and only saved
if there are references. ID based structures include armatures and
meshes, but not bones. It would not be very hard to alter the code to
use plain allocations and copying the structure over to the guardedalloc
chunks, all we would need is to follow the Python parent link rather
than the Bone parent link so that the actual pointer to the Bone
structure is not duplicated.

> The way you have changed it - it now no longer makes python
> representation of objects and immediately allocates memory for a C
> structure. The problem with this is that if someone repeatedly calls a
> script the bone will be recreated in memory over and over using up
> physical memory until blender exits.
That is only different if you have a script that creates bones which it
then discards without adding them to armatures. If the script would add
the newly created bones to armatures anyway, this version just uses less
temporary storage in the Python objects. How common do you believe it is
to use Blender.Armature.Bone.New() without later using
armature.addBone() on the new bones? There is no difference for the
get mode, this change affects only bone creation.