On Mon, Aug 9, 2010 at 13:54, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> On Mon, Aug 9, 2010 at 12:11 PM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> On Mon, Aug 9, 2010 at 11:51 AM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>...
>>> * new API svn_wc_translated_file3():
>>> svn_client_translated_file(const char ** resultfile,
>>> svn_boolean_t * copyCreated,
>>> const char * wcfile,
>>> svn_boolean_t deleteOnPoolCleanup,
>>> apr_uint32_t flags,
>>> apr_pool_t* pool)
>>>
>>> the flags would be the same as now: SVN_WC_TRANSLATE_FORCE_EOL_REPAIR and
>>> SVN_WC_TRANSLATE_FORCE_COPY.
>>> The API would work like this:
>>> if SVN_WC_TRANSLATE_FORCE_COPY and SVN_WC_TRANSLATE_FORCE_EOL_REPAIR is not
>>> specified and the BASE file is available locally and uncompressed, just
>>> return the path to that file.
>>> Else create a temp copy of the BASE file and return that path.
>>> deleteOnPoolCleanup of course would get ignored if the file is available
>>> locally uncompressed and both SVN_WC_TRANSLATE_FORCE_COPY and
>>> SVN_WC_TRANSLATE_FORCE_EOL_REPAIR are not specified.
>>>
>>> The bool copyCreated would get set to true by the API if it created a copy
>>> and set to false if it just returned the path to the existing BASE file.
>>>
>>> That way, I could get the file very fast if it's possible, but still would
>>> get the file in a slow way if it's not possible.
>>
>> Whatever we do, I'm -1 on any solution that uses bitflags.
>
> Daniel suggests some context here. We've been burned in the past by
> APIs which use bitflags (see svn_wc__entry_modify()). Not that there
> is any guarantee of badness, but bitflags tend to add obfuscation and
> control flow difficulties to a function. And it's just plain hard to
> read.
>
> I realize that booleans are functionally equivalent, and may take a
> bit more typing, but I'd suggest we use them wherever possible,
> especially in out public API.
>
> -Hyrum (who offers the following for clarification of his feelings,
> not with the intent to start a religious war)
I have the same feelings about bitflags. Switching to booleans, or
simply using several functions (ie. instead of bools to alter "big"
semantics), is much more preferable.
And yes, I also realize Stefan was just using flags as a demonstrative
placeholder...
Cheers,
-g
p.s. and even more asinine is using "apr_uint32_t" for the flags
rather than a plain fuckin' "int".
Received on 2010-08-09 21:20:42 CEST