[Bf-taskforce25] Proposal: Blender API revisited

[vekoon]

Starting with d) I think that's definitely a non-issue. Also, we could 
make it blend in more nicely by doing one of two things. First you 
export at API level an "Operator" type so that operators are just some 
additional stuff in the API from the scripter point of view, some 
abstracted blenderwise concept of tool. So you do something like:
op = bpy.api.Operator('OBJECT_OT_clear_location')
op.run()
Or you could just define operators like some user stuff, by which I mean 
create a clear definition-wise distinction for operators. I prefer the 
first solution.

For c) I think this is really more of a design choice, of where to put 
the required checks. I'd put required checks directly in the API calls 
where possible (i.e. for things that could cause unexpected behavior), 
while operators should check only for user/context level stuff which 
should then not matter for direct API.

If with a) you mean you change main core functions then preprocessing 
API will definitively give compiler error. I don't believe you meant 
operators should directly call the BlenderAPI version? Like in 
API_function_call()? as the latter approach should be avoided imo.
Yes for new operators that could happen, but I think this is somehow a 
self-fixing issue as people who need that particular API function will 
complain about it being missing. I know it's a lame second best, but we 
can make everything perfect. Another option could be to publicly 
flagellate devs who do so?


Brecht Van Lommel wrote, on 20/03/2009 19.52:
> 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.
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>