Rename NET_API to NET_EXPORT, and rename NET_TEST to NET_EXPORT_PRIVATE.

Rename NET_API to NET_EXPORT, and rename NET_TEST to NET_EXPORT_PRIVATE.
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=96560

[darin (slow to review), 2011-08-10 21:47:06]

I went with NET_EXPORT_PRIVATE instead of NET_EXPORT_FOR_TESTING or
NET_EXPORT_TEST because NET_EXPORT_FOR_TESTING is longer and NET_EXPORT_TEST is
still a bit confusing when read.  I also found that it made sense to refer to
these exports as private because that's really what they are.

I didn't find that this required too much indentation fixup.

[rvargas (doing something else), 2011-08-11 01:25:29]

LGTM. Thanks.

http://codereview.chromium.org/7529043/diff/8001/net/disk_cache/disk_cache.h
File net/disk_cache/disk_cache.h (right):

http://codereview.chromium.org/7529043/diff/8001/net/disk_cache/disk_cache.h#...
net/disk_cache/disk_cache.h:147: class NET_EXPORT_PRIVATE Entry {
Could you make this a NET_EXPORT?. My mistake.

[wtc, 2011-08-11 18:51:48]

http://codereview.chromium.org/7529043/diff/8001/net/base/net_export.h
File net/base/net_export.h (right):

http://codereview.chromium.org/7529043/diff/8001/net/base/net_export.h#newcode22
net/base/net_export.h:22: #endif  // defined(NET_IMPLEMENTATION)
The reason these macros are named XXX_API is that they
are defined as either __declspec(dllexport) or
__declspec(dllimport).

To a programmer familiar with Windows, an XXX_EXPORT macro
seems to imply __declspec(dllexport).

Are you avoiding the use of "API" deliberately?
XXX_API and XXX_API_PRIVATE sound fine to me.

[darin (slow to review), 2011-08-11 21:46:41]

On 2011/08/11 18:51:48, wtc wrote:
> The reason these macros are named XXX_API is that they
> are defined as either __declspec(dllexport) or
> __declspec(dllimport).
> 
> To a programmer familiar with Windows, an XXX_EXPORT macro
> seems to imply __declspec(dllexport).
> 
> Are you avoiding the use of "API" deliberately?
> XXX_API and XXX_API_PRIVATE sound fine to me.

There was a large thread about this on chromium-dev@.

In a nut-shell, I think it confuses matters to mix the issue
of exporting functions from a DLL with declaring what is or
isn't public API.  Also, we do not need to add XXX_API to inline
functions, and yet inline functions can very much be part of an
official public API.

My hope was to just use NET_EXPORT in place of NET_API and NET_TEST,
but since Ricardo put the effort in to categorize these functions,
and because this is a first step toward defining a real public API
for the net/ module, I did not want to undo his work.  I have not
introduced XXX_EXPORT_PRIVATE in any other module, and I really hope
not to.

I think NET_EXPORT_PRIVATE will be difficult to maintain properly.
People will misuse it.  They will start using such a function from
places other than unit tests, and there will be no mechanism to
prevent that mistake.  net/ OWNERS are not expected to review patches
in other modules that make use of the net code.

I prefer to put private functions in an internal namespace, but
there may be other approaches that work.  We should try to find
solutions that are less error prone for distinguishing private
from public API.

I agree that XXX_EXPORT might sound like it could only mean
__declspec(dllexport), but then I thought about this from the point
of view of a DLL users, and for them (your consumers) "export"
makes sense.  You can see also that other libraries, like V8, already
use a macro with EXPORT in the name (V8EXPORT).

Another reason to stay away from XXX_API.  In the WebKit API, we
sometimes need to export private functions.  It seemed to be a bit
confusing to mark a private function with WEBKIT_API since by
definition a function in a private section of a class cannot be
API.  (We have some inline methods calling non-inline private
functions.)

Anyways, this all leads me to believe that XXX_EXPORT is the way to
go for all Chrome components.  I plan to also create a CHROME_EXPORT
macro so that we can make linking unit_tests.exe much much much
faster in the component build.  We will export all of the symbols
from chrome.dll that the unit tests require.  CHROME_API would
certainly not make any sense, and using CHROME_API_PRIVATE could
work, but it also seems to incorrectly classify the code needing to
be exported since chrome.dll really has no API.

Hope this helps!
-Darin