3 ms·

Nothing about that indicates it's OOP or not. > I have to go through an additional level of indirection before I truly understand how Month is implemented I'

Nothing about that indicates it's OOP or not. > I have to go through an additional level of indirection before I truly understand how Month is implemented I'd just hover over it in my IDE and it'd tell me what it is. Regardless, "Month" tells me it's a "month" whereas "int" tells me "lol get fucked I ain't telling you shit" The "do" example there is much more readable than the "don't" example. Especially in any further usages of it, as it's one less thing I need to keep track of. That is, I don't need to second guess if the variable was passed to the wrong thing since the compiler is validating that for me. I don't need to track that during my "reading" > True but as a developer who has to read and fix code, I do have to worry about the implementation details because the bugs could be in implementation details Then why are you arguing against it? A "Month" type cleanly restricts the implementation details to a specific controllable set, which an "int" does not and is a free for all. You're in for a nightmare trying to fix people doing math with dates if you use "ints", whereas you can pretty easily fix all of the users of a "Month" or "Date" type by just removing the math operators (or "fixing" them to work appropriately) and letting the compiler spot all the mistakes.

MaulingMonkey 4y ago
> Regardless, "Month" tells me it's a "month" whereas "int" tells me "lol get fucked I ain't telling you shit" I disagree. Is "Month" a 1-based month ordinal? A 0-based month index? A string containing user input that should be preserved in it's original form to avoid data loss (be that "jan", "JAN", "January", "1", ...)? Memoized? An indirect reference to OCR data? Do I even have a guarantee it's on the Gregorian calendar, or am I in the context of some calendar app that might support chinese lunar calendars? Is it JSON serializable? Is it a localization placeholder? Is it an integer typedef that means different things in different contexts, including "months ago" in some relative timestamp formatting code? "Month" tells me jack shit that the function and variable names didn't. "int" at least tells me I can math it, and that if I'm dumb enough to have memcpy-serialized code, I have a potential porting hazard in the form of endian issues - and size variance if I'm dumb enough to target an ILP64 platform. Based on personal experience, these are far more likely bugs for me to encounter and need to fix than any that would be caught by stronger month typing. There is a place for stronger types - I'm not complaining about Rust's SystemTime/Instant/Duration trifecta and more - but "Month" ain't it. It's a bridge too far, too pointless - it is the wrong abstraction. And, yes, you can math on months. For indexing into arrays of localized strings, for conversion to/from epoch... I've written some really nasty .natvis visualizers that rendered absolute timestamps as PST timestamps for debug convenience, and it involved a whole lot of rather redundant and duplicated math in that horror of an XML format which would be made 10 times worse by extra "help" in the form of strong types to be unwrapped. > I'd just hover over it in my IDE and it'd tell me what it is. This works until some jerk buries it in #ifdef soup and causes your IDE to lie. Perhaps uint8_t - except on windows where it might be int for "backwards compatability". Or perhaps multiple definitions in different independent contexts (be that different namespaces or different included headers.) I've seen stupider shit frequently enough that the habit of spending more time performing a more thorough check than a simple hover will be time well spent. > you can pretty easily fix all of the users of a "Month" type Nah, that kind of underbaked leaky misabstraction isn't going to be properly thought out well enough to simply fix by merely poking at the type (and I'm confident in assuming it will be an underbaked leaky misabstraction on account of the lack of value provided.) You're going to have to actually audit all use of that type for dumb abstraction-breaking assumptions that make it brittle and fragile if you so much as sneeze on it's layout. A saving grace here: so little code will actually bother to use it, that it actually shouldn't be too terrible. Probably.
- Jtsummers 4y ago
  You really think having a type tells you less than having an int? Is the int 0 or 1 based? You don't know. Does the int handle rollover? Nope, you have to. Of course, that's the C way. Worse is better. Fuck sensible type systems and use of them. Let the world burn. You can look up types, with a bare int you have to pray someone documented it and that they were consistent.
  - MaulingMonkey 4y ago
    > You really think having a type tells you less than having an int? In the case of "Month", yes. Give me stronger types for dates or timespans or instants though. > Does the int handle rollover? Nope, you have to. Rollover tends to need handling at the date level to carry the year, so let's be honest, "Month" won't handle rollover properly on it's own either.
    - kllrnohj 4y ago
      > Give me stronger types for dates or timespans or instants though. So the guideline you're vigorously arguing against you don't actually disagree with at all, you just really, really hate Month for seemingly no reason. Maybe give the guideline a read rather than just the 2 line snippet someone else posted? > "Month" won't handle rollover properly on it's own either. It does by not offering math operators in the first place, avoiding the entire possibility of a rollover from the outset. Or it could throw on rollover so it's at least an runtime exception instead of a silent failure.
- kllrnohj 4y ago
  > Is "Month" a 1-based month ordinal? A 0-based month index? Unlike with an bare int, a "Month" type has places to actually document all that. So your counter argument, which is entirely the same for an int anyway, is utterly absurd. > This works until some jerk buries it in #ifdef soup and causes your IDE to lie. I don't really know what your point even is here. Your ide or code base is bad, therefore everyone should share your pain? If your ide can't resolve it then go look up the docs the old fashioned way. It's the same end result of a wrapper type being vastly superior to a bare int. I can make a comment in a header or a man page or whatever for a "Month" type to answer all your questions. I could never do the same for an "int" variable. It really sounds like you're just wanting to obsessively nitpick the specific example of "Month" than anything about what the guideline is even saying. If you're just too lazy to make a Month then sure knock yourself out. But at least be honest that you're just being lazy in the now with a hope it doesn't bite you later, don't pretend you're making an actually better or more readable decision. We all take the lazy out from time to time.
noobermin 4y ago
Note, the person you're replying too is talking about fixing code, not using code. A mouse-over tip will tell you what it is. If code is broken due to it being bad abstractions, you will need to know how it is implemented regardless. And like below someone retorting below "hurr that's just bad code then" well all code is bad. Some people just seem to think their own machines will think for them or even worse, some other developer thought for them and didn't make any mistakes. Others realize people are infallible and you need installed hatches in order to get in there and fix things, and they prefer systems where it is easier to do so. I feel like the big exception to this are very large libaries which can hire multiple SV-salaried engineers to work on them full-time (STL, Qt, etc), because yes, they likely might have done a good job. But some in some small shop C++ code, the constraints are different, the expected correctness is different, and you just can't trust that people have done everything right and it helps to have hatches. Anyway, there are other issues with a Month type but other than that issue, the use of a const accessor method is yes better than public member, so I don't fully agree with them that the 1st guideline is that bad, I certainly agree with the spirit of it to a degree. I skimmed the guide and a lot of it is pretty good. Like C.2 really jives with me and gives me a very good rule that seems to explain why a lot of OOP code rubs me the wrong way, of which encapsulating a bunch of disparate state with no real invariants or constraints makes no sense but is something you see from a lot of code out there. That said, I still will never follow anything religiously, even if Bjarne Stroustrup wrote it because really no rules fit every situation and devs should be wary when people make pronouncements of rules that are total and fixed.
- kllrnohj 4y ago
  > If code is broken due to it being bad abstractions, you will need to know how it is implemented regardless. Sure, but the type (and thus the guideline) is still helping with that instead of hurting. I can much more easily find all usages of a broken `Month` type than I can an int representing a month which could be named anything. > That said, I still will never follow anything religiously, even if Bjarne Stroustrup wrote it because really no rules fit every situation Oh definitely, I don't agree/follow all of those guidelines either. The guidelines themselves don't pitch themselves as that, and many of the "rules" have whole sections listing reasonable exceptions and why those exceptions are OK.

MaulingMonkey 4y ago

> Regardless, "Month" tells me it's a "month" whereas "int" tells me "lol get fucked I ain't telling you shit" I disagree. Is "Month" a 1-based month ordinal? A 0-based month index? A string containing user input that should be preserved in it's original form to avoid data loss (be that "jan", "JAN", "January", "1", ...)? Memoized? An indirect reference to OCR data? Do I even have a guarantee it's on the Gregorian calendar, or am I in the context of some calendar app that might support chinese lunar calendars? Is it JSON serializable? Is it a localization placeholder? Is it an integer typedef that means different things in different contexts, including "months ago" in some relative timestamp formatting code? "Month" tells me jack shit that the function and variable names didn't. "int" at least tells me I can math it, and that if I'm dumb enough to have memcpy-serialized code, I have a potential porting hazard in the form of endian issues - and size variance if I'm dumb enough to target an ILP64 platform. Based on personal experience, these are far more likely bugs for me to encounter and need to fix than any that would be caught by stronger month typing. There is a place for stronger types - I'm not complaining about Rust's SystemTime/Instant/Duration trifecta and more - but "Month" ain't it. It's a bridge too far, too pointless - it is the wrong abstraction. And, yes, you can math on months. For indexing into arrays of localized strings, for conversion to/from epoch... I've written some really nasty .natvis visualizers that rendered absolute timestamps as PST timestamps for debug convenience, and it involved a whole lot of rather redundant and duplicated math in that horror of an XML format which would be made 10 times worse by extra "help" in the form of strong types to be unwrapped. > I'd just hover over it in my IDE and it'd tell me what it is. This works until some jerk buries it in #ifdef soup and causes your IDE to lie. Perhaps uint8_t - except on windows where it might be int for "backwards compatability". Or perhaps multiple definitions in different independent contexts (be that different namespaces or different included headers.) I've seen stupider shit frequently enough that the habit of spending more time performing a more thorough check than a simple hover will be time well spent. > you can pretty easily fix all of the users of a "Month" type Nah, that kind of underbaked leaky misabstraction isn't going to be properly thought out well enough to simply fix by merely poking at the type (and I'm confident in assuming it will be an underbaked leaky misabstraction on account of the lack of value provided.) You're going to have to actually audit all use of that type for dumb abstraction-breaking assumptions that make it brittle and fragile if you so much as sneeze on it's layout. A saving grace here: so little code will actually bother to use it, that it actually shouldn't be too terrible. Probably.

Jtsummers 4y ago
You really think having a type tells you less than having an int? Is the int 0 or 1 based? You don't know. Does the int handle rollover? Nope, you have to. Of course, that's the C way. Worse is better. Fuck sensible type systems and use of them. Let the world burn. You can look up types, with a bare int you have to pray someone documented it and that they were consistent.
- MaulingMonkey 4y ago
  > You really think having a type tells you less than having an int? In the case of "Month", yes. Give me stronger types for dates or timespans or instants though. > Does the int handle rollover? Nope, you have to. Rollover tends to need handling at the date level to carry the year, so let's be honest, "Month" won't handle rollover properly on it's own either.
  - kllrnohj 4y ago
    > Give me stronger types for dates or timespans or instants though. So the guideline you're vigorously arguing against you don't actually disagree with at all, you just really, really hate Month for seemingly no reason. Maybe give the guideline a read rather than just the 2 line snippet someone else posted? > "Month" won't handle rollover properly on it's own either. It does by not offering math operators in the first place, avoiding the entire possibility of a rollover from the outset. Or it could throw on rollover so it's at least an runtime exception instead of a silent failure.
kllrnohj 4y ago
> Is "Month" a 1-based month ordinal? A 0-based month index? Unlike with an bare int, a "Month" type has places to actually document all that. So your counter argument, which is entirely the same for an int anyway, is utterly absurd. > This works until some jerk buries it in #ifdef soup and causes your IDE to lie. I don't really know what your point even is here. Your ide or code base is bad, therefore everyone should share your pain? If your ide can't resolve it then go look up the docs the old fashioned way. It's the same end result of a wrapper type being vastly superior to a bare int. I can make a comment in a header or a man page or whatever for a "Month" type to answer all your questions. I could never do the same for an "int" variable. It really sounds like you're just wanting to obsessively nitpick the specific example of "Month" than anything about what the guideline is even saying. If you're just too lazy to make a Month then sure knock yourself out. But at least be honest that you're just being lazy in the now with a hope it doesn't bite you later, don't pretend you're making an actually better or more readable decision. We all take the lazy out from time to time.

noobermin 4y ago

Note, the person you're replying too is talking about fixing code, not using code. A mouse-over tip will tell you what it is. If code is broken due to it being bad abstractions, you will need to know how it is implemented regardless. And like below someone retorting below "hurr that's just bad code then" well all code is bad. Some people just seem to think their own machines will think for them or even worse, some other developer thought for them and didn't make any mistakes. Others realize people are infallible and you need installed hatches in order to get in there and fix things, and they prefer systems where it is easier to do so. I feel like the big exception to this are very large libaries which can hire multiple SV-salaried engineers to work on them full-time (STL, Qt, etc), because yes, they likely might have done a good job. But some in some small shop C++ code, the constraints are different, the expected correctness is different, and you just can't trust that people have done everything right and it helps to have hatches. Anyway, there are other issues with a Month type but other than that issue, the use of a const accessor method is yes better than public member, so I don't fully agree with them that the 1st guideline is that bad, I certainly agree with the spirit of it to a degree. I skimmed the guide and a lot of it is pretty good. Like C.2 really jives with me and gives me a very good rule that seems to explain why a lot of OOP code rubs me the wrong way, of which encapsulating a bunch of disparate state with no real invariants or constraints makes no sense but is something you see from a lot of code out there. That said, I still will never follow anything religiously, even if Bjarne Stroustrup wrote it because really no rules fit every situation and devs should be wary when people make pronouncements of rules that are total and fixed.

kllrnohj 4y ago
> If code is broken due to it being bad abstractions, you will need to know how it is implemented regardless. Sure, but the type (and thus the guideline) is still helping with that instead of hurting. I can much more easily find all usages of a broken `Month` type than I can an int representing a month which could be named anything. > That said, I still will never follow anything religiously, even if Bjarne Stroustrup wrote it because really no rules fit every situation Oh definitely, I don't agree/follow all of those guidelines either. The guidelines themselves don't pitch themselves as that, and many of the "rules" have whole sections listing reasonable exceptions and why those exceptions are OK.