6 ms·

> That’s why languages don’t represent dates as just as struct with ints In C, `struct tm` is literally a struct whose fields are all `int`s. But people typic

> That’s why languages don’t represent dates as just as struct with ints In C, `struct tm` is literally a struct whose fields are all `int`s. But people typically represent time in C programs as an integer of some width measuring time in some fixed unit since some fixed point in time. > - there is a Date class that knows how to semantically add days to dates taking leap years into account, time zones, etc. That supports our point.... > > Then will your class take into account that the calendar changed in the mid 1600s(?). If you need to calculate dates and compare dates. I can't anticipate those requirements---maybe our date class has to bomb out if you pass in, say, 1800 or -5 as a year because someone on my team insists they're invalid. People work around these classes when they have to do date arithmetic because they're too slow, or they depend on the machine's locale and the locale isn't under control, or they take timezones into account in fundamentally broken ways, or any number of other reasons. >> If you have a special SensorReadingId type and you change what it is, all your code breaks at once and you get a hell of a mess to untangle. > > How so? All of your other code should be treating it like an opaque type. That's a fantasy. When you wrote your reply, you deleted all the parts of my post explaining "how so"---why not all of your other code is going to treat it like an opaque type. > You shouldn’t have to do it in but one place. The serializer would call your .ToString() method anyway. You just override it. I don't want to convert your boxed int to a string and then parse it as an integer just to do math on it. That creates a ton of syntactic noise, not to mention being slow. > Versioning and deprecating APIs and interfaces is a solved problem. Yes, and the solution is a pain in the ass! So don't create new interfaces to version and deprecate for no good reason. > I thought we were specifically not talking about low level languages and you mentioned Java. When would that be an issue in Java? I didn't mention Java. > I wouldn’t be sending my Account class that probably has business logic in it across the wire. I would be mapping it to a dumb AccountModel POCO/POJO with something like Automapper. And I'd just send an integral id over the wire, probably documenting that it's the id of an account using something like the field's name in the message. No extra tooling needed, and I don't have to make a fuss about how the id() function (that I had to add to the Account object anyway) is for the big boys and should be avoided whenever possible. People rapidly get themselves into deep shit when they find out their overcooked codebase is too slow to be useful. The class names remain but their structure and function and any semblance of the clean abstraction they used to provide are the first things to go.

scarface74 8y ago
In C, `struct tm` is literally a struct whose fields are all `int`s. But people typically represent time in C programs as an integer of some width measuring time in some fixed unit since some fixed point in time. Even C has a bunch of functions to work with the date struct as an opaque type.... I can't anticipate those requirements---maybe our date class has to bomb out if you pass in, say, 1800 or -5 as a year because someone on my team insists they're invalid. People work around these classes when they have to do date arithmetic because they're too slow, or they depend on the machine's locale and the locale isn't under control, or they take timezones into account in fundamentally broken ways, or any number of other reasons. And then you use a better class. In Java you use something like JodaTime in .Net you use NodaTime - a .Net library written and maintained by Jon Skeet (the person with the highest ranking on Stack OverFlow). If that’s not good enough you write a custom extension or mixin to handle your special snowflake handling and still let all of the consumers treat it as an opaque type. I don't want to convert your boxed int to a string and then parse it as an integer just to do math on it. That creates a ton of syntactic noise, not to mention being slow. We were talking about an accountId that just happens to be represented as an int. You’re not going to be doing math on an account id. Also neither .Net with generics or even C++ templates have the boxing and unboxing issue. Yes, and the solution is a pain in the ass! So don't create new interfaces to version and deprecate for no good reason. If there was a business case to change the underlying structure - by definition there was a “good reason”. And I'd just send an integral id over the wire, probably documenting that it's the id of an account using something like the field's name in the message. No extra tooling needed, and I don't have to make a fuss about how the id() function (that I had to add to the Account object anyway) is for the big boys and should be avoided whenever possible. Even so, you should still not send your internal representation that may change across the wire and do some type of mapping. Are you going to send the same model that came from your ORM that’s tied directly to your database across as the representation to the outside world?
- tmyklebu 8y ago
  > Even C has a bunch of functions to work with the date struct as an opaque type.... Yes, for conversion to/from time_t, formatting, and parsing. That's my point; you use the integral type whenever you don't care whether it was a Thursday because the integral type isn't going to waste your time. > And then you use a better class. In Java you use something like JodaTime in .Net you use NodaTime - a .Net library written and maintained by Jon Skeet (the person with the highest ranking on Stack OverFlow). If that’s not good enough you write a custom extension or mixin to handle your special snowflake handling and still let all of the consumers treat it as an opaque type. Stop with the hero worship. You should do things that make sense in context. Recommending that everyone use a library in all contexts because it's written by Jon Skeet is a ridiculous thing to do. (BTW, it seems like the Joda-Time people recommend you use the standard java.time package instead.) > We were talking about an accountId that just happens to be represented as an int. You’re not going to be doing math on an account id. Also neither .Net with generics or even C++ templates have the boxing and unboxing issue. Who are you to say I won't do math on account ids? > If there was a business case to change the underlying structure - by definition there was a “good reason”. In the situations the two of us have discussed, there is no business case to create these interfaces in the first place. Where is the good reason? > Even so, you should still not send your internal representation that may change across the wire and do some type of mapping. Are you going to send the same model that came from your ORM that’s tied directly to your database across as the representation to the outside world? What ORM? What database? If I'm using an ORM and a database, high-performance time operations are likely out of the question.

scarface74 8y ago

In C, `struct tm` is literally a struct whose fields are all `int`s. But people typically represent time in C programs as an integer of some width measuring time in some fixed unit since some fixed point in time. Even C has a bunch of functions to work with the date struct as an opaque type.... I can't anticipate those requirements---maybe our date class has to bomb out if you pass in, say, 1800 or -5 as a year because someone on my team insists they're invalid. People work around these classes when they have to do date arithmetic because they're too slow, or they depend on the machine's locale and the locale isn't under control, or they take timezones into account in fundamentally broken ways, or any number of other reasons. And then you use a better class. In Java you use something like JodaTime in .Net you use NodaTime - a .Net library written and maintained by Jon Skeet (the person with the highest ranking on Stack OverFlow). If that’s not good enough you write a custom extension or mixin to handle your special snowflake handling and still let all of the consumers treat it as an opaque type. I don't want to convert your boxed int to a string and then parse it as an integer just to do math on it. That creates a ton of syntactic noise, not to mention being slow. We were talking about an accountId that just happens to be represented as an int. You’re not going to be doing math on an account id. Also neither .Net with generics or even C++ templates have the boxing and unboxing issue. Yes, and the solution is a pain in the ass! So don't create new interfaces to version and deprecate for no good reason. If there was a business case to change the underlying structure - by definition there was a “good reason”. And I'd just send an integral id over the wire, probably documenting that it's the id of an account using something like the field's name in the message. No extra tooling needed, and I don't have to make a fuss about how the id() function (that I had to add to the Account object anyway) is for the big boys and should be avoided whenever possible. Even so, you should still not send your internal representation that may change across the wire and do some type of mapping. Are you going to send the same model that came from your ORM that’s tied directly to your database across as the representation to the outside world?

tmyklebu 8y ago
> Even C has a bunch of functions to work with the date struct as an opaque type.... Yes, for conversion to/from time_t, formatting, and parsing. That's my point; you use the integral type whenever you don't care whether it was a Thursday because the integral type isn't going to waste your time. > And then you use a better class. In Java you use something like JodaTime in .Net you use NodaTime - a .Net library written and maintained by Jon Skeet (the person with the highest ranking on Stack OverFlow). If that’s not good enough you write a custom extension or mixin to handle your special snowflake handling and still let all of the consumers treat it as an opaque type. Stop with the hero worship. You should do things that make sense in context. Recommending that everyone use a library in all contexts because it's written by Jon Skeet is a ridiculous thing to do. (BTW, it seems like the Joda-Time people recommend you use the standard java.time package instead.) > We were talking about an accountId that just happens to be represented as an int. You’re not going to be doing math on an account id. Also neither .Net with generics or even C++ templates have the boxing and unboxing issue. Who are you to say I won't do math on account ids? > If there was a business case to change the underlying structure - by definition there was a “good reason”. In the situations the two of us have discussed, there is no business case to create these interfaces in the first place. Where is the good reason? > Even so, you should still not send your internal representation that may change across the wire and do some type of mapping. Are you going to send the same model that came from your ORM that’s tied directly to your database across as the representation to the outside world? What ORM? What database? If I'm using an ORM and a database, high-performance time operations are likely out of the question.