7 maj 2013 kl. 01.00 skrev Daniel Shahaf:
> Of course there is, if someday APR uses "invalid option" in another
> meaning than the one this patch assumes it does.
Believe it or not, that is already how gettext translation works. If
you think that really is a problem, then Subversion has got it in
spades. Every time we mark up a string for translation with _(), there
is the danger that someone will add an identical string in another
meaning somewhere else, and nothing will alert us to the fact.
I admit feeling uneasy about this myself the first time I saw gettext,
but have come to understand that it is quite robust in practice --
witness the thousands of software packages successfully doing
translation that way, Subversion included.
The main "danger", which I have mentioned before, is marking up
strings that are too short or ambiguous in nature, in particular
single words like "merge" or "yes". Such strings should generally be
avoided or, if they cannot be, use gettext contexts (which are not
used anywhere in Subversion yet). However, something as verbose as
"%s: invalid option: %s\n" should be quite safe, and is not atypical
of strings in our message catalogue.
(In addition, the very fact that these strings are sent to the
function that should print out error messages during option parsing
serves as a tremendously strong disambiguating force.)
> That's why API promises exist: so anticipating won't be needed. The
> API
> promises something and you work to that. The API doesn't promise you
> something and you don't presume it'll happen.
We use the API to good effect here, as well as common sense. Regarding
the semantics, I think everyone will agree that if APR tells the error
printer "invalid option" during option parsing, it won't diverge much
if at all in meaning for the next couple of centuries, no matter how
wildly APR changes.
Note that the strings passed to the errfn never affect the logic of
the program in any way, only their translations. This is also an
interface of sorts, but a softer, human interface, the interface of
translations, which carries its own rules and logic.
> Well yeah, it could grow an enum.
>
> Or it could just promise that "invalid option" in the 2nd replaceable
> argument will always be okay to translate. That doesn't require any
> code changes, just a decision by the APR devs not to introduce other
> meanings to that particular string in the future.
Either would do, but neither is really necessary. In practice, the APR
getopt code is as inert as they come - it basically hasn't been
touched in over a decade. But sure, we could work on APR, and this
patch would work nicely in the meantime.
> I've missed the previous report of that problem. (Is that why Jens is
> on the CC? I haven't seen him in a while.)
It was mentioned in the first message of this thread:
http://svn.haxx.se/dev/archive-2008-05/1445.shtml
(Jens, sorry to bother you, but I didn't anticipate such a lengthy
discussion, and included you since you showed an interest in the past.
If you want some peace and quiet, please don't hesitate to tell us off.)
Received on 2013-05-07 21:44:53 CEST