> My point is that even if no plugin uses the fields you still can't just go
> and change them without consideration.
Not without consideration, but here's a perfectly valid thing we could do if
the members are not "public":
```c
// before
struct GeanyFoo {
gboolean do_not_delete_all_files;
};
// after
struct GeanyFoo {
gboolean delete_all_files;
};
```
As long as the structure layout doesn't change, we are free to use that slot as
we wish.
> How's this a problem?
The more API we expose, particularly unnecessarily, the more we have to
maintain compatibility with, and the greater the chance that we will break
plugins if we need/want to change it, not to mention confusing the API by
exposing/documenting types that cannot be used (like the `GeanyBuild*` ones you
fixed in this PR). It's one thing if a plugin developer makes a request and
asks to have some part of the API exposed in order to be able to write the
plugin, but it's quite different to just start exposing new API in the middle
of a PR that is simply meant to correct/improve existing API documentation,
especially when you haven't even explained why the size and layout of the
structure needs to be known by GI, given that the member is after all public
members in a structure that is only ever used by pointer.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/commit/302b40e9778ff49407902f3ef9f272ed202f4547#commitcomment-15078186
