On 02.02.2015 17:09, Ivan Zhakov wrote:
> On 2 February 2015 at 18:55, Branko Čibej <brane_at_wandisco.com> wrote:
>> On 02.02.2015 16:33, Ivan Zhakov wrote:
>>> On 2 February 2015 at 18:24, <brane_at_apache.org> wrote:
>>>> Author: brane
>>>> Date: Mon Feb 2 15:24:16 2015
>>>> New Revision: 1656488
>>>> URL: http://svn.apache.org/r1656488
>>>> Introduce a private libsvn_client context structure that stores
>>>> context information that should not be part of the public API.
>>>> * subversion/include/svn_client.h
>>>> (svn_client_ctx_t): Remove the 'progress' field, which should be private.
>>>> * subversion/libsvn_client/client.h
>>>> (client_ctx_t): New; the private context struct.
>>>> Contains the equivalent of the 'progress' field.
>>> I suggest svn_client__private_ctx_t name for client_ctx_t structure: I
>>> think it less confusing name and follow our guidelines for library
>>> private identifiers.
>> This is not really a library private identifier. It is a type name
>> private to the library, so it's never exposed from a (static or dynamic)
>> library and therefore cannot cause name collisions at link time.
>> We use similar type and macro naming shortcuts in many places for this
>> kind of thing.
>> I'll probably add a "private_" prefix, though, to avoid confusion where
>> both context types are used in the same function.
> I know that there is no name collision problem with type names. But
> Subversion Community Guide still require library prefix even for
> structure names :
> All published functions, variables, and structures must be signified
> with the corresponding library name - such as libsvn_wc's
> svn_wc_adm_open. All library-internal declarations made in a
> library-private header file (such as libsvn_wc/wc.h) must be signified
> by two underscores after the library prefix (such as
> I think that svn_client__private_ctx_t structure name will be clearer
> for readers since it gives a context where this type come from.
Well, here's the thing: we don't use this convention for type names in
many, many places. I wouldn't want to downplay HACKING, but surely we
can make some changes every 15 years or so? At least to make HACKING
match reality, instead of expecting things the other way around. :)
Received on 2015-02-02 17:19:34 CET