[Bf-committers] Blender 2.5 api proposal.

[joe]

On Mon, Dec 1, 2008 at 12:48 PM, Timothy Baldridge <tbaldridge at gmail.com>wrote:

> > 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.


Nah it's not too bad.  A lot of things map fairly well.  I don't think we've
really had much trouble in this area.  It's not nearly as hard as it might
look.

>
>
> 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.


Not really, the modifier system works using a quasi-OOP design itself, using
DerivedMesh to access data.  And we do have standard functions for
manipulating several kinds of lists.


>
> 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()
> obj.modifiers.append(mod)


That's how most of the py API works already.  It's actually not all that
hard to write custom list wrappers when you need them.

>
>
> 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++.


That'd require rewriting most of the core blender code, which isn't really
worth it for the benefits (especially since C++ is so much more complicated
than C).

>
> The issue isn't really the fact we're using C, or any procedural/OOP
clashes (remember python supports both an OOP and a procedural approach to
things).  What ton was talking about specifically is that the new API should
always try and use the appropriate C API in blender to do things, even if
the part of the code someone's trying to wrap in python doesn't use that API
itself yet (in which case the py coder would have to rework it to use the
API, or something like that).

Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20081202/8ce499be/attachment-0001.htm