@LarsGit223 at least `projfilecmds` is being accessed outside `build.c`, in 
`project.c`, so it's not actually completely private to `build.c`.  If it was, 
build.h should have had the forward declaration, and `build.c` the complete one.

@ntrel `struct _GeanyEntryActionPrivate` and `struct 
_GeanyMenubuttonActionPrivate` are forward declarations because the definition 
is totally private, in the corresponding source file (that includes its 
header).  This is perfectly fine IMO because not only it's the only way to make 
a structure totally opaque, but the forward declaration is also included by the 
code having the definition, so the compiler can do a check that those are 
compatible.
Some of the ones you mentioned are to break circular dependencies (e.g. 
search.h's one looks like that), so we don't have much choice.  All others that 
aren't required for breaking circular dependencies should be removed and the 
proper header included IMO.

> The point of including headers explicitly per-file is to reduce dependencies 
> on source files. 

It also helps controlling what uses what, and have more generic parts not 
entangled between them.
But that's not really the point IMO, we could have a single header and that'd 
be mostly fine by me.  What matters IMO is that declarations can be checked 
against their definition, to avoid conflicts and such.  If declarations start 
popping everywhere, it makes it a *lot* harder to change them or check if they 
make sense.  OK a structure can only change name (which is bad enough), but if 
we'd extend this to e.g. prototypes it's diving into madness if that function 
signature becomes incorrect.
So basically my take is, as much as possible, keep only one declaration (in the 
.h) to have minimal effort when modifying it, and have that declaration be used 
together with the definition (.h included in the .c) so the compiler can 
actually check the declaration is correct for us.

This makes this change not worth it IMO, as it trades a tiny bit of compilation 
time for maintenance and safety costs. That's not a deal I'm wanting to make.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/2299#issuecomment-531468537

Reply via email to