Would it be possible to have the function take an enum instead of an int on top of whatever other solution you guys use?
Its really telling watching this conversation how useful it would be. You guys are talking about 0, 1 and 2 which is completely meaningless without reading documentation or source code and in fact it would be super easy for people to even start confusing the meaning of the values in this conversation. If instead the parameter were something like: kDontCheck, kCheckNameOnly, kCheckNameAndHost - but named more in the libcurl style - then in code as well as in conversation it would be a lot more difficult to do or say the wrong thing. Imagine if fseek told you to use 0,1 and 2 instead of SEEK_SET, SEEK_CUR, SEEK_END. There would be a lot more file i/o bugs out there, and you'd constantly have to dig up documentation to remember which value did which behavior (does 0 seek to the end? or is that 2?) The upside: making the enum values be equal to the correct integers means old code still works with 0,1 and 2, but the documentation can be updated to say to use these enum values. The downside: It would be nicer if users were FORCED to use the enum (compiler error), or strongly suggested (compiler warning). But unfortunately I know of no way in C or C++ to cause an error when an int is used instead of an enum (if anyone else does it would be rad to see it!), and while i think that it makes a compile warning when you use an int instead of an enum (i forget for sure), going through the generic type of function call that this setting is set through makes it impossible to set the parameter expected as an enum so that's out too unfortunately. To really see what i mean, check out these two peices of text from this conversation, the first as is, with magic numbers, the second with symbolic constants. Origional: I thus suggest we simply ban 1 as a value in an upcoming release. This will fource users to use 2 instead and when copying such code back to older libcurl-using code that will improve the code running there as well! With symbolic constants: I thus suggest we simply ban kCheckNameOnly as a value in an upcoming release. This will fource users to use kCheckNameAndHost instead and when copying such code back to older libcurl-using code that will improve the code running there as well! Much clearer what the suggestion is, isn't it? The same would be true when reading code or documentation. On Oct 28, 2012 10:17 AM, "Daniel Stenberg" <[email protected]> wrote: > On Sun, 28 Oct 2012, Peter Sylvester wrote: > > I thought making 1 identical to 2, and offering a 3 as a replacement, if >> someone really wants the behavior. This would be an uncompatible change but >> probably work in most cases ?? >> > > Sure, that *could* be done but that extra option is rarely used (properly) > and isn't supported by all SSL backends anyway so I think of it as a good > time to simplify as well while we're at it! > > -- > > / daniel.haxx.se > ------------------------------**------------------------------**------- > List admin: > http://cool.haxx.se/list/**listinfo/curl-library<http://cool.haxx.se/list/listinfo/curl-library> > Etiquette: > http://curl.haxx.se/mail/**etiquette.html<http://curl.haxx.se/mail/etiquette.html> >
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
