[Bf-taskforce25] Proposal: Blender API revisited

[Shaul Kedem]

--> i'd say go for it

I think so too, without seeing the thing work I just can't visualize how
good/bad its going to be. this is the best theoretical concept you have and
it's probably going to be the best one any of us have before going the trial
and error path.

On Fri, Mar 20, 2009 at 7:25 PM, Michael Fox <mfoxdogg at gmail.com> wrote:

> +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
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090320/eb0569a2/attachment-0001.htm