[Github-comments] [geany/geany] filetypesprivate.h: Don't include build.h (#2299)

Colomban Wendling notifications at xxxxx
Sat Sep 14 10:23:24 UTC 2019


@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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20190914/a0acae02/attachment-0001.html>


More information about the Github-comments mailing list