[Bf-taskforce25] Proposal: Blender API revisited

[Nathan Vegdahl]

Ack, sorry Brecht.  I misunderstood your e-mail, and stupidly didn't
look closely at the code examples.  What you're doing is what I was
talking about.  I'm just dumb. ;-)

So yeah, this looks really good to me.
+1

I still think it would be good to give the user the option to echo API
calls to the console.  It would be hugely useful.  But I don't think I
know enough about Python integration to really give informed opinions
on the topic from a technical side.  It would just be great from the
user perspective, though.
But anyway, it can be tackled later.

--Nathan V


On Fri, Mar 20, 2009 at 9:48 AM, Brecht Van Lommel <brecht at blender.org> wrote:
> 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.
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>