[Bf-committers] Blender 2.5 api proposal.
tbaldridge at gmail.com
Mon Dec 1 20:48:52 CET 2008
> What remains is a lot of calls like "Add constraint" or "Delete
> modifier", which is currently a very undefined piece of Blender code,
> closely tied to the buttons for such options. At this moment it's well
> possible we don't tackle all of that via Operators, still allowing
> direct callbacks to buttons (just for the sake of simpler migration).
It seems to me that part of these issues come from the fact that we're
trying to squish the rather procedural API of C into the OOP based
programming of Python.
I'm assuming the issue with things like modifier stacks is that
currently every list of objects in Blender uses a different method of
data modifiying? So in some cases we have linked lists and other times
we have vectors (arrays). Perhaps what we need is a Standard Template
Library for blender. In this way we can make the internal Blender code
more closely match the Python code.
It seems to me that the best way way to have Python access the
modifier stacks would be with Python lists:
obj = getObject("MyBlenderObject")
mod = BuildModifyer()
But while we're on the subject of rewriting everything, should we
stick with C instead of C++? Now I know, most C++ code is often (or
perhaps most times) abused, but well written C++ code can aid
readability. It seems to me that allot of Blender code could be
simplified by using the OOP-ness of C++. In general the 3d tool set
is object based. We take a object and set the transform and rotation
attributes of that object. We use modifiers to warp object. It seems
that the code should express this to some extent. In the end it's
really 6 of one half a dozen of the other, but C++ would help new
coders make a easier transition from Python to C++.
Two wrights don't make a rong, they make an airplane. Or bicycles.
More information about the Bf-committers