On Mon, Aug 9, 2010 at 13:54, Hyrum K. Wright <hyrum_wri...@mail.utexas.edu> wrote: > On Mon, Aug 9, 2010 at 12:11 PM, Hyrum K. Wright > <hyrum_wri...@mail.utexas.edu> wrote: >> On Mon, Aug 9, 2010 at 11:51 AM, Stefan Küng <tortoise...@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".
