[Bf-taskforce25] Proposal: Blender API revisited

[vekoon]

Was operators in "and not have the operators call any auto-generated 
functions" a typo I guess? Because when I said auto-generated bridge 
functions I meant functions that are generated in the makesapi module 
and used only in the makesapi module. They're basically meant to 
automatically convert parameters from BlenderAPI parameters list to C 
functions, they have nothing to do with operators.

Initially when designing the API I did want to put it in the various 
modules but then decided not to. The reason for this is that API "code" 
is actually just creation of meta description for Blender's 
core/module/kernel functions. There's no real code in the makesapi 
module except for the code that handles the definition/access of course. 
The API export is just those API_def_* calls. So because it's just 
meta-code in the end it could be put in a separate location without 
generating too much confusion because in the end its peculiarity is that 
it exports functionality while instead what type of functionality (i.e. 
object, scene or whatever) is secondary as there's not really any code 
that cares or reference that, just the included headers.
Also the other advantage in having it separate is that it can be 
preprocessed (like RNA) which not only is faster but as I said can 
generate bridge functions automatically, otherwise you'd have to define 
those yourself (which I think creates even more confusion).

I agree that having API+operators generates doc duplication but that's a 
good deal if you consider what not having an API at all would mean. Also 
this could partially be tackled if we just add a function that iterates 
through the parameters for an API function and adds properties to the 
operator accordingly.

 From the example code you posted it seems you want to make API like 
static functions? I really think for a very complex application API like 
Blender was (and ultimately will end up being again) a Type system is 
more suitable in that it allows for better distinction. Think for 
instance of py constraints, py nodes, Game Engine etc. They're already 
logically an object system which makes them very well fit into a type 
system.

Anyway those were just some points. I think the important fact was just 
to realize there was a need for an advanced API parallel to operators so 
that we could also avoid complicating operators too much. I pretty much 
agree that's more important now to continue on making 2.5 functional and 
then bother with additional details for the API. At most this will mean 
retouching operators a little which is not that big of a deal anyway.


Brecht Van Lommel wrote, on 20/03/2009 15.30:
> Hi,
>
> After some more discussion on IRC, here is another proposal, not unlike
> the Blender API one, but with some tweaks to get it more feasible and
> incremental.
>
> a) Blender 2.5 is about tools and the event system, and operators remain
> just that. They are always context sensitive. Getting blender
> functionality working as such tools is the #1 priority for 2.5.
>
> b) A secondary low level API provides access for python scripts. This is
> very much like the Blender API proposal. What I would like to see
> different there however is that it should be defined in the editor
> modules (close to the operators), and not have the operators call any
> auto-generated functions.
>
> c) Operators are still available for python to call, but they are
> context sensitive. This means they are mostly useful in macro like
> scripts. The low level API permits to do context-less operations.
>
>
> To demonstrate what this means in practice, let me show an example. This
> is the current delete objects operator:
> http://pasteall.org/4641/c
>
> This is how it would look in the earlier context-decoupled method:
> http://pasteall.org/4640/c
>
> And here it is using a separate operator and low level python function:
> http://pasteall.org/4642/c
>
> Advantages:
> - Low level python functions can be added incrementally, not interfering
> with 2.5 targets much.
> - Operator design does not get complicated further.
> - There is a clear distinction between operators and python functions,
> permitting better API design.
>
> Disadvantages:
> - Means we will likely release 2.5 with reduced python functionality.
> How much depends on efforts to improve the API.
> - Duplicate code in defining operator properties and function
> parameters.
> - Effort is needed to get operators accessible context-less for python.
> Unavoidable in any design?
>
> Brecht.
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>