[Bf-taskforce25] Proposal: Blender API revisited

[Brecht Van Lommel]

Hi Nathan,

On Fri, 2009-03-20 at 09:09 -0700, Nathan Vegdahl wrote:
> This looks almost identical to what I proposed, except that it's
> written much more clearly, and operators don't use the low-level API
> to do their work.
> 
> The reason I suggested that operators do their work through the
> low-level API is because it ensures that the low-level API is
> complete.  At least it does once all the operators have been ported,
> which can be done over time.

Can you be more precise about how this is different, in terms of code,
comparing with the delete objects prototype code I posted? All proposed
methods are very similar, the difference is in the details.

One thing I did not mention is that I think it would be good to put the
functions under "low level" and "python api" in object_api.c, and the
ones under "operator" in object_ops.c, in this code:
http://pasteall.org/4642/c

> One of the things I love about the operator design is that it ensures
> that everything the user can do, Python can do, because anything
> exposed to the user *has* to be implemented as an operator.
> I think it's important that any low-level API have similar assurances
> of completeness.  So I suggest again that the goal be to eventually
> port operators to use the API to do work with actual data.  I may be
> missing some important implementation details, but it seems like this
> would be straight-forward.
> 
> Some secondary benefits:
> - Reduced code duplication.

If the operator and API function are different things, how does this
remove code duplication? I'm talking about duplication of documentation,
and specifying parameter types. Code duplication of the core code does
not happen in any of the proposals.

> - The blender console could echo API calls in addition to operator
> calls.  This is great for learning the API, or just refreshing your
> memory how to do something if you forgot.

It is not clear to me how to do this if the operator is a different
thing than the API function. Unless the API call would actually be a
call to some intermediate auto-generated thing. I'm not a big fan of
introducing that kind of abstraction in the code, makes things hard to
follow. There can be some abstracting on the "outside" but on the inside
it is good to keep it straightforward C code in my opinion.

Brecht.