[Bf-taskforce25] Proposal: Blender API revisited

[Brecht Van Lommel]

After some IRC discussion with Campbell, some issues that came up (hope
I'm summarizing this well). The comments on the issues are mine, not a
consensus between us :).


a) Lazy developers will only update Operators and not the API.

Once an operator uses an API function call, changing the operator
properties will require the API function to be updated too. If that gets
out of sync, it should generate a compile error or at least a compiler
warning.

There's still the issue though that for new operators no API function
may be added. I don't think it would be more work than doing
context-decoupling of the operator, but if they are separate things it's
easier to make excuses..

b) Code duplication.

As vekoon mentioned, we could let the operators copy properties and
description from the API function. It would do the job I think.

c) API may not get tested well.

The core code that runs is the same for Operators and API. What can go
wrong is that the API function does not do some check but instead does
it in the operator (e.g. for library linking). If other operators do
this correct I guess it will stand out? Not sure if there are other
typical mistakes that could be made.

d) Python will have "two API's".

This is true, though it is not entirely bad in my opinion. You would be
able to call a tool, or call a member function on an object, they would
be quite different styles of scripting anyway?

Some operators will not have a corresponding API function because they
are not useful there, and some API functions will not be useful as an
operator. For the ones that do have both, they would still be consistent
if properties and description are copied from the API function to the
operator.


I don't have a good answer to all these issues, but from my point of
view the tradeoffs are acceptable?

Brecht.