[Bf-committers] RNA write access for CurveMap

[Lukas Tönne]

> I tried to do this once before by adding an index value to the
> CurveMap(?) struct so they could be dereferenced into the enclosing
> CurveMapping but it was rejected by Campbell.

Yeah, it's far from beautiful code ... but at least this does not
require additional index or backpointer to CurveMapping, just the
index parameter in the CurveMapping function. Could also be done with
a direct CurveMap pointer parameter for clarity (plus internal
validity check). This is "only" an RNA extension to expose some C
functionality.

> This way doesn't really fit into the rest of the rna functions (not to
> mention py-dogma) since you're operating on a 'child' through the
> 'parent' interface.
>
> But, alas, this one little thing is the *only* reason you can't create
> materials using the py-api so it really needs a good solution.

Yes, there are a couple of places where this is a problem (e.g.
nodes). Most of the time you get away simply because the parent is the
ID data block, which is always passed along with the child pointer
itself, but often that is not the case. Here are a few possible
solutions that i can think of:

0) Make child data read-only (duh!)
1) Child update actually becomes parent update, with additional
parameter to the child in question and validity check. Maybe this can
be formalized a bit with specialized update function definitions in
RNA for child data.
2) Look up the parent from the library data each time a child updates,
i.e. go over all possible parents in the ID data block and search for
the child. Only works for library data and could be extremely costly
if done often (iirc particle systems do this, see psys_find_object)
3) Store backpointer in children where necessary. Means data and
maintenance overhead, especially for small structs (e.g. CurveMapPoint
-> CurveMap -> CurveMapping)