4 ms·

> with alternatives you can easily make errors in and which make understanding the code harder blacklist/whitelist => blocklist/allowlist how's that making th

> with alternatives you can easily make errors in and which make understanding the code harder blacklist/whitelist => blocklist/allowlist how's that making the code harder to understand ? or errorprone ?

rfoo 6y ago
Maybe because it is inappropriate to use blocklist/allowlist in all cases, so to replace blacklist/whitelist people have to come up with a few different words (blocklist, badlist, denylist, etc) and apply them accordingly. It is certainly pretty confusing to see similar concepts expressed in a few different words, I'd prefer an umbrella word in this case. Of course if we are going to say "blocklist is the word replacing blacklist and it'll go into textbook you don't have to think deeply about it just remember this is the word you must use in all cases" the problem would disappear, but I'm afraid we can't. Master/Slave demonstrate this better. For example, in the context of pseudoterminals, primary/secondary is certainly not precise words to use, it is quite hard to come up with "obvious" words without re-educating everyone. (oh, and it's baked in the API name in various specifications, like "ptsname" => "pseudo terminal slave name")
- codegladiator 6y ago
  The leader/follower for master/slave seems pretty clear, similarly for blocklist/allowlist. Your argument seems to be 'because we have been doing it like this' or 'has been used in so many places' which I don't agree with too much as a reason to keep using it. This change seems to actually bring in better terms and clearly understandable.
  - rfoo 6y ago
    Sorry, but if you actually click into the link before arguing with me, you would see they replaced "master" and "slave" in pseudoterminal context with "tty" and "processTty", not leader/follower because their relationship are really not leader and follower. https://go-review.googlesource.com/c/go/+/236857/5/src/os/signal/internal/pty/pty.go https://go-review.googlesource.com/c/go/+/236857/5/src/os/si...
    - codegladiator 6y ago
      Fair enough. I did check the link but didn't see that one.

rfoo 6y ago

Maybe because it is inappropriate to use blocklist/allowlist in all cases, so to replace blacklist/whitelist people have to come up with a few different words (blocklist, badlist, denylist, etc) and apply them accordingly. It is certainly pretty confusing to see similar concepts expressed in a few different words, I'd prefer an umbrella word in this case. Of course if we are going to say "blocklist is the word replacing blacklist and it'll go into textbook you don't have to think deeply about it just remember this is the word you must use in all cases" the problem would disappear, but I'm afraid we can't. Master/Slave demonstrate this better. For example, in the context of pseudoterminals, primary/secondary is certainly not precise words to use, it is quite hard to come up with "obvious" words without re-educating everyone. (oh, and it's baked in the API name in various specifications, like "ptsname" => "pseudo terminal slave name")

codegladiator 6y ago
The leader/follower for master/slave seems pretty clear, similarly for blocklist/allowlist. Your argument seems to be 'because we have been doing it like this' or 'has been used in so many places' which I don't agree with too much as a reason to keep using it. This change seems to actually bring in better terms and clearly understandable.
- rfoo 6y ago
  Sorry, but if you actually click into the link before arguing with me, you would see they replaced "master" and "slave" in pseudoterminal context with "tty" and "processTty", not leader/follower because their relationship are really not leader and follower. https://go-review.googlesource.com/c/go/+/236857/5/src/os/signal/internal/pty/pty.go https://go-review.googlesource.com/c/go/+/236857/5/src/os/si...
  - codegladiator 6y ago
    Fair enough. I did check the link but didn't see that one.