4 ms·

In my opinion, when you have an internal boolean flag for two behaviors, the interface you should probably expose isn't the flag in one function, but two differ

In my opinion, when you have an internal boolean flag for two behaviors, the interface you should probably expose isn't the flag in one function, but two different functions.

dataflow 6y ago
So like std::ios_base::fmtflags should actually be 19+ different functions and/or classes?
- criddell 6y ago
  That isn't a boolean flag.
  - dataflow 6y ago
    Each bit is a Boolean flag (hex, scientific, etc.)... they're just packed into an integer. (Nobody said you have to use N bools for N different flags...)
    - eska 6y ago
      So does this API look well-designed to you?
MaxBarraclough 6y ago
edit I see I'm late, dataflow already made this point. I'll leave this here anyway. This rule of thumb is often useful but there are many exceptions. As an example, the internal behaviour of this OpenCL function [0] is presumably quite different depending on which bits of the second parameter are set, but it's still a good design as all possible behaviours of the function are still closely related as far as the user is concerned. [0] https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xhtml/clCreateBuffer.html https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xht...
- jrimbault 6y ago
  But you made the point much better than dataflow. Their comment is borderline incendiary. And yes there are exceptions, that's why my comment had so many rhetorical devices to defuse those silly arguments. My comment is specifically about "booleans and two behaviors" and even then I don't affirm it as the only valid way, only as my opinion and not in all cases.
  - dataflow 6y ago
    Come on... I made a point in my first comment, you either miss or ignore it, I cite an example to maybe get it across in case it's more vivid with a obvious example, and instead of at least acknowledging the point and maybe disagreeing with it, you ignore it and say it's "incendiary" and "silly" to post such a vivid example? The counterexample isn't some weird exception; it's quite typical, and especially pertinent for this particular case. The point I've been making is: std::thread is an absolutely terrible candidate for something that you can expect to only have "two behaviors" moving forward. This isn't even a prediction; you just have to look at current platform APIs to see this. I'd cite Windows's CREATE_SUSPENDED as one example of another flag you might want, but someone would inevitably complain and tell me that's just the Windows API being unnecessarily overcomplicated. So, instead, go ahead and check out the sheer behemoth that is POSIX's "simple" interface: the pthread_attr API used to specify different behaviors for pthread_create. It's not just a flag, it's not just a struct... it's a list of structs where each one contains flags as well as other things. And Linux's clone() is the other extreme, where they pack a gazillion flags (read: behaviors) into one integer parameter for thread creation where you'd think it'd leave a little more room for extensibility. Thread creation isn't just something that might need "more than two behavior", it's pretty much the diametric opposite of "two behaviors" if I've ever seen one!
    - jrimbault 6y ago
      I did not say what you said is "incendiary", I said it is "borderline incendiary". It's not incendiary since it is true, but it is expressed in such a pythy fashion as to be almost incendiary. Especially when I crafted my original comment to specifically acknowledge those cases. Between your answer and MaxBarraclough's, one is tonally a quickwitted mean quip and the other is a well articulated and well meaning response.
kzrdude 6y ago
A strategy template parameter works well in this case - parameterize the type.
- dataflow 6y ago
  I'd disagree on that. That would create 2 unrelated types when in fact one of the classes here semantically really is more like a subclass of the other one. Additionally, that creates additional work for the compiler both for this class (makes it hard to put the definition in an implementation file) and for its users (containers will now get instantiated and codegened for each type separately).

In my opinion, when you have an internal boolean flag for two behaviors, the interface you should probably expose isn't the flag in one function, but two different functions.

dataflow 6y ago

So like std::ios_base::fmtflags should actually be 19+ different functions and/or classes?

criddell 6y ago
That isn't a boolean flag.
- dataflow 6y ago
  Each bit is a Boolean flag (hex, scientific, etc.)... they're just packed into an integer. (Nobody said you have to use N bools for N different flags...)
  - eska 6y ago
    So does this API look well-designed to you?

MaxBarraclough 6y ago

edit I see I'm late, dataflow already made this point. I'll leave this here anyway. This rule of thumb is often useful but there are many exceptions. As an example, the internal behaviour of this OpenCL function [0] is presumably quite different depending on which bits of the second parameter are set, but it's still a good design as all possible behaviours of the function are still closely related as far as the user is concerned. [0] https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xhtml/clCreateBuffer.html https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xht...

jrimbault 6y ago
But you made the point much better than dataflow. Their comment is borderline incendiary. And yes there are exceptions, that's why my comment had so many rhetorical devices to defuse those silly arguments. My comment is specifically about "booleans and two behaviors" and even then I don't affirm it as the only valid way, only as my opinion and not in all cases.
- dataflow 6y ago
  Come on... I made a point in my first comment, you either miss or ignore it, I cite an example to maybe get it across in case it's more vivid with a obvious example, and instead of at least acknowledging the point and maybe disagreeing with it, you ignore it and say it's "incendiary" and "silly" to post such a vivid example? The counterexample isn't some weird exception; it's quite typical, and especially pertinent for this particular case. The point I've been making is: std::thread is an absolutely terrible candidate for something that you can expect to only have "two behaviors" moving forward. This isn't even a prediction; you just have to look at current platform APIs to see this. I'd cite Windows's CREATE_SUSPENDED as one example of another flag you might want, but someone would inevitably complain and tell me that's just the Windows API being unnecessarily overcomplicated. So, instead, go ahead and check out the sheer behemoth that is POSIX's "simple" interface: the pthread_attr API used to specify different behaviors for pthread_create. It's not just a flag, it's not just a struct... it's a list of structs where each one contains flags as well as other things. And Linux's clone() is the other extreme, where they pack a gazillion flags (read: behaviors) into one integer parameter for thread creation where you'd think it'd leave a little more room for extensibility. Thread creation isn't just something that might need "more than two behavior", it's pretty much the diametric opposite of "two behaviors" if I've ever seen one!
  - jrimbault 6y ago
    I did not say what you said is "incendiary", I said it is "borderline incendiary". It's not incendiary since it is true, but it is expressed in such a pythy fashion as to be almost incendiary. Especially when I crafted my original comment to specifically acknowledge those cases. Between your answer and MaxBarraclough's, one is tonally a quickwitted mean quip and the other is a well articulated and well meaning response.

kzrdude 6y ago

A strategy template parameter works well in this case - parameterize the type.

dataflow 6y ago
I'd disagree on that. That would create 2 unrelated types when in fact one of the classes here semantically really is more like a subclass of the other one. Additionally, that creates additional work for the compiler both for this class (makes it hard to put the definition in an implementation file) and for its users (containers will now get instantiated and codegened for each type separately).