[Bf-committers] DNA structs with local scope

[Julian Eisel]

Hi,

let me try to make my motivation a bit clearer, long-ish read ahead :)

I'd say this is really about code architecture. Simply put I want to
improve modularity and force people to use abstractions/APIs rather
than manipulating data directly. We barely use any abstractions for
DNA struct members, we simply access them all over the place (since we
can include their header file directly).

This summer I spent a lot of time with going through the code base to
change all low-level accesses of layer bits-fields. This would've been
a matter of minutes if there were API functions, like
BKE_object_layer_is_visible(...). Now, I'm in a similar situation with
integrating workspaces into the existing design and there have been
many similar situations before.
And of course, API usage can greatly improve readability
(BLI_object_layer_is_visible(...) vs. (v3d->lay & ob->lay) != 0). I'm
really passionate when it comes to code readability and can't stress
its importance enough.

Let me use custom-manipulators as another example: There are structs
for managing the individual manipulators, their states, their
updating, etc, *and I don't want any code outside of the wmManipulator
module to directly access or even change their data!* Right now, they
are local structs and other parts of the code can request information
from them *through an API*. It's however well possible that I'll have
to move these structs into DNA to support file read/write of
manipulator states. Right now that would mean moving them into a
global DNA file, allowing people to bypass the API and manipulating
data directly.
We can of course simply ask developers to use APIs/abstractions, but
in the code I maintain I would really prefer to force doing this. With
the current global DNA headers I won't be able to do so though.

Another thing: On one hand we're really strict about not calling any
WM functions from BKE, on the other hand we can simply include
DNA_windowmanager_types.h in BKE and access the WM structs directly
(and we actually do this). IMHO the only code that should know how the
wmWindow struct looks like, is the WM code itself, or even only
wm_window.c. If any other part of the code wants to manipulate data of
a wmWindow instance, it should do so through an API. (This is just an
example, I don't propose to change this now.)

I agree with what Hermann said, all this is probably a consequence
from the ancient global shared data design of Blender. What I want to
do is to move away from global data and move towards a more modular,
API based design to make maintenance and refactoring easier - at least
in the code modules I work in and maintain. Hence my proposal to allow
local DNA headers.

Cheers,
- Julian -

On 9 December 2016 at 20:07, Ichthyostega <prg at ichthyostega.de> wrote:
> On 09.12.2016 18:04, Julian Eisel wrote:
>> I wanted to discuss a thing about DNA that I really don't like: DNA structs
>> are always placed in headers that we allow to access globally within the
>> source code.
>
> to me this looks like a direct consequence of Blender being built round
> a common global shared data model. And I agree with you, today you would
> think twice before starting a new *large scale* application with that
> kind of architecture. But that is another story.
>
> OTOH, I would also be reluctant to hide the underlying architecture,
> with some kind of markup or metadata. Let's just face it: in Blender,
> every part is a tool that works on a common model, and it's up to
> the developers to use that power wisely.
>
> Cheers,
> -- Hermann
>
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers