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" <daniel_at_haxx.se> 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
Received on 2012-10-28