Hacker News new | ask | show | jobs
by thegeekpirate 281 days ago
> Back to the CURL prefix, what is wrong with it?

It prevents stuttering when using it `curl.CURL_*`.

> What would the "CURL" distinct type be without the CURL prefix?

`CURL` isn't a prefix there.

Take more time to think things through.
1 comments
johnisgood 281 days ago
I did, thank you. Please explain why would anyone (end user of library) ever want "curl.CURL_GLOBAL_ALL", for example? If anything, it should be private. If you really want to go there, sure. I think it is YOU who should think things through. I get that you are filled with hatred, but come on man. Think. Why would anyone want to call "curl.CURL_GLOBAL_ALL" from a binding which is supposed to be used as a high-level curl library? If it is possible (I have no idea) to make it private, then it should be made private. It is not intended to be used by the users of the library, is it? The higher level functions are the ones supposed to be used by them, and they seem to be named correctly from a quick glance.

If you reply, do so without ad hominems and with some respect. Thank you.

link
thegeekpirate 281 days ago
Last question I'll answer, because you aren't doing any of this is good faith.

You mean `curl.GLOBAL_ALL`, and it's for https://curl.se/libcurl/c/curl_global_init.html

link
johnisgood 281 days ago 

  // CURL_GLOBAL_ALL combines all initialization flags.
  CURL_GLOBAL_ALL: i64 = 3
It has nothing to do with "curl_global_init()". This - which is a high-level function intended to be called by the users of the library - has:

  init :: proc() -> (ok: bool) {
    return curl_global_init(CURL_GLOBAL_ALL) == 0
  }
As you can see, higher-level function calls low-level function. The higher-level function does not have "curl" as the prefix.

My question still stands and has not been answered.

link