"Coupling," in the "classical" sense, means that changes to
one portion of a code base require changes elsewhere.
Coupling means that changes in one place affect (many) other
places. This is the meaning the word has always had, and the
meaning with which it is almost universally used. If you want
to restrict its meaning to something else, fine. Just don't be
surprised if no one understands you.
Requiring recompilation, within an application, is only a
trivial form of coupling, and in this enables the compiler to
have significantly more information as it compiles each
translation unit.
I'm not sure I understand that sentence. If what you're trying
to say is that compilation dependencies are not as serious a
form of coupling as source code dependencies, fine. We agree on
that. That doesn't mean that you can neglect compilation
dependencies. They tend to chain: in one real project, we found
that before using the compilation firewall idiom, source codes
of around a thousand lines resulted in the compiler seeing
between 500 thousand and 2 million lines after preprocessing.
Use of the compilation firewall brought that figure down to
around 20 thousand. That had two major impacts: compile times
dropped drastically (that was on an older machine, but even
today, reading 2 million lines over the LAN takes time), and
significantly less files needed to be recompiled after a small
change in the implementation details of the class.
I work mainly on commercial applications. With all due
respect, you don't know what you're talking about.
It's the client code which ends up paying for your extra
includes, not the library itself.
[...]
Yes, it does. Most application-internal functions are called
in only a few places.
It occured to me after posting that you seem to be confusing two
issues. The fact that a function is inline doesn't mean that
you don't need both a declaration and a definition. In order
for the definition to serve as the declaration, it has to be in
the class. Do that, and you quickly end up with the unreadable
mess we know from Java. It's a nice feature for demo programs,
but once the class has more than three or four functions, and
the functions have more than two or three lines, the results are
completely unreadable.
To make sure that every function's interface and
implementation are maintained by separate people? Rubbish.
To have a different procedure for modifying the interface than
for modifying the implementation is essential. In large
projects, it will almost always be a case of different people;
in small projects, it may be the same person wearing a different
hat. But the impact of changing an interface is significantly
different than that of changing an implementation.
The fact that I prefer to inline more functions than you do
does not justify your claim of "bad engineering." This
brow-beating and insulting of people with whom you disagree is
petty and unbecoming.
It's not a question of more or less. Inline functions increase
coupling, and cause maintenance problems. Good software
engineering avoids them except in special cases.