5 ms·

> instead duplicating the code-paths (leaving incr/decr untouched and instead making mult_ versions of everything) If there already are two arithmetic opcodes,

by jhgb 5y ago

> instead duplicating the code-paths (leaving incr/decr untouched and instead making mult_ versions of everything) If there already are two arithmetic opcodes, shouldn't both of them already be handled by the same code, only with an operation parameter? In that case all that should be necessary is the handling of that parameter in the place where the operation is actually performed, and you only add one more value of that parameter. Having said that, I haven't looked and memcached yet how it actually implements these operations. I'll have to do that.

TobTobXX 5y ago
That's the problem: Since only incr and decr exist, a bool is enough to say which of these two operatios should be done. But when you add a third, the bool isn't enough. So you either change the opcode to an int, like the autor, or branch the mul instruction away above like above solution.
- cletus 5y ago
  Two rules I learned early that served me well: 1. If you don't do arithmetic on it and it's not a primary key then it's not a number (eg an employee number might be "123456" but it's a string not a number); and 2. It's almost never a boolean; it's an enum. I've lost count of the number of times I've had to change a boolean to an enum (some of which I created in the first place). My favourite hack for this is when someone decides to add a third value to a boolean with: Optional<Boolean> foo Nope. You're wrong. It's even more hilarious when they add a fourth value: @nullable Optional<Boolean> foo
  - aidenn0 5y ago
    https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_
  - db48x 5y ago
    Yea, I would prefer an enum over an int to choose the operation, but don’t forget that this is C, where enums _are_ ints. Oh well. Also, that it turns out there is already an enum to extend for the binary protocol, so the blog author reused that instead of making a new one just for the this one function.

by jhgb 5y ago

TobTobXX 5y ago

That's the problem: Since only incr and decr exist, a bool is enough to say which of these two operatios should be done. But when you add a third, the bool isn't enough. So you either change the opcode to an int, like the autor, or branch the mul instruction away above like above solution.

cletus 5y ago
Two rules I learned early that served me well: 1. If you don't do arithmetic on it and it's not a primary key then it's not a number (eg an employee number might be "123456" but it's a string not a number); and 2. It's almost never a boolean; it's an enum. I've lost count of the number of times I've had to change a boolean to an enum (some of which I created in the first place). My favourite hack for this is when someone decides to add a third value to a boolean with: Optional<Boolean> foo Nope. You're wrong. It's even more hilarious when they add a fourth value: @nullable Optional<Boolean> foo
- aidenn0 5y ago
  https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_
- db48x 5y ago
  Yea, I would prefer an enum over an int to choose the operation, but don’t forget that this is C, where enums _are_ ints. Oh well. Also, that it turns out there is already an enum to extend for the binary protocol, so the blog author reused that instead of making a new one just for the this one function.