[Bf-taskforce25] Proposal: Blender API revisited

[Michael Fox]

+1 from for this proposal

On Fri, 2009-03-20 at 19:52 +0100, Brecht Van Lommel wrote:
> 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..

this is a risk we have to take

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

I think this is not a worry as if the op/tool works surly the call from
py will work

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


anyway this is the best we have atm, i'd say go for it

> 
> 
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
-- 
Michael Fox 
Developer and user of Blender3d
www.blender.org

mfoxdogg at gmail.com