5 ms·

> 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 po

> 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
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. What else are you going to do in C? But even most real world implementations of C have all sorts of structs and typedefs that you shouldn’t make any assumptions about and you should treat as an opaque type. Who are you to say I won't do math on account ids? Is that really what you are going to argue? That in a real world use case you’re going to be doing math on an accountId? What ORM? What database? If I'm using an ORM and a database, high-performance time operations are likely out of the question. So you’re going to pass a raw key/value record set around your code and program like it was 2006? So now you’re going back to mapping your sql resultset to an object that makes sense anyway. Going right back to my point that you’re going to have a mapping between your raw results -> domain model -> view model (where the view model is serialized for external use) and back again anyway.
- tmyklebu 8y ago
  > What else are you going to do in C? But even most real world implementations of C have all sorts of structs and typedefs that you shouldn’t make any assumptions about and you should treat as an opaque type. Subtract two times? (BTW, struct tm isn't an opaque type.) > > Who are you to say I won't do math on account ids? > Is that really what you are going to argue? That in a real world use case you’re going to be doing math on an accountId? You seem to think that's absurd? Maybe I want to store a set of accountids. So I sort them (bit-extraction or comparison!), take deltas (subtraction!), and encode the deltas sensibly. Maybe I have two lists of accountids and I want to check that none of the things in the first list show up in the second list. Some sort of hashing scheme (bit-fiddling!) is going to be my friend here. > > What ORM? What database? If I'm using an ORM and a database, high-performance time operations are likely out of the question. > So you’re going to pass a raw key/value record set around your code and program like it was 2006? So now you’re going back to mapping your sql resultset to an object that makes sense anyway. Going right back to my point that you’re going to have a mapping between your raw results -> domain model -> view model (where the view model is serialized for external use) and back again anyway. What SQL? What resultset? What object? I have an integer. Why do you assume it doesn't make sense?
  - scarface74 8y ago
    You seem to think they hat's absurd? Maybe I want to store a set of accountids. So I sort them (bit-extraction or comparison!), You’re going to do “bit extraction” to sort? If you treat accountId as an opaque type, you are going to have a comparison operator as part of the type and the rest of your code is going to just use a < or > symbol. take deltas (subtraction!), and encode the deltas sensibly. Maybe I have two lists of accountids and I want to check that none of the things in the first list show up in the second list. Some sort of hashing scheme (bit-fiddling!) is going to be my friend here. Or in a modern language since you have already defined equality between the two types and overridden the GetHashCode() function.... var deltas = accountList1.Except(accountlist2) Why are you doing that all through your code instead of encapsulating the concept of equality, less than and greater than in one place? What SQL? What resultset? What object? I have an integer. Why do you assume it doesn't make sense? You were referring to CRUD apps and having to serialize the Account object. Either you are using an ORM, you are getting results from a database as a record set - which is usually represented by a dictionary of key value pairs and mapping it to your Account class or you are sending back a raw record set. More than likely, you are mapping from your domain model to your externally exposed view model anyway.
deleted 8y ago
[deleted]

scarface74 8y ago

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. What else are you going to do in C? But even most real world implementations of C have all sorts of structs and typedefs that you shouldn’t make any assumptions about and you should treat as an opaque type. Who are you to say I won't do math on account ids? Is that really what you are going to argue? That in a real world use case you’re going to be doing math on an accountId? What ORM? What database? If I'm using an ORM and a database, high-performance time operations are likely out of the question. So you’re going to pass a raw key/value record set around your code and program like it was 2006? So now you’re going back to mapping your sql resultset to an object that makes sense anyway. Going right back to my point that you’re going to have a mapping between your raw results -> domain model -> view model (where the view model is serialized for external use) and back again anyway.

tmyklebu 8y ago
> What else are you going to do in C? But even most real world implementations of C have all sorts of structs and typedefs that you shouldn’t make any assumptions about and you should treat as an opaque type. Subtract two times? (BTW, struct tm isn't an opaque type.) > > Who are you to say I won't do math on account ids? > Is that really what you are going to argue? That in a real world use case you’re going to be doing math on an accountId? You seem to think that's absurd? Maybe I want to store a set of accountids. So I sort them (bit-extraction or comparison!), take deltas (subtraction!), and encode the deltas sensibly. Maybe I have two lists of accountids and I want to check that none of the things in the first list show up in the second list. Some sort of hashing scheme (bit-fiddling!) is going to be my friend here. > > What ORM? What database? If I'm using an ORM and a database, high-performance time operations are likely out of the question. > So you’re going to pass a raw key/value record set around your code and program like it was 2006? So now you’re going back to mapping your sql resultset to an object that makes sense anyway. Going right back to my point that you’re going to have a mapping between your raw results -> domain model -> view model (where the view model is serialized for external use) and back again anyway. What SQL? What resultset? What object? I have an integer. Why do you assume it doesn't make sense?
- scarface74 8y ago
  You seem to think they hat's absurd? Maybe I want to store a set of accountids. So I sort them (bit-extraction or comparison!), You’re going to do “bit extraction” to sort? If you treat accountId as an opaque type, you are going to have a comparison operator as part of the type and the rest of your code is going to just use a < or > symbol. take deltas (subtraction!), and encode the deltas sensibly. Maybe I have two lists of accountids and I want to check that none of the things in the first list show up in the second list. Some sort of hashing scheme (bit-fiddling!) is going to be my friend here. Or in a modern language since you have already defined equality between the two types and overridden the GetHashCode() function.... var deltas = accountList1.Except(accountlist2) Why are you doing that all through your code instead of encapsulating the concept of equality, less than and greater than in one place? What SQL? What resultset? What object? I have an integer. Why do you assume it doesn't make sense? You were referring to CRUD apps and having to serialize the Account object. Either you are using an ORM, you are getting results from a database as a record set - which is usually represented by a dictionary of key value pairs and mapping it to your Account class or you are sending back a raw record set. More than likely, you are mapping from your domain model to your externally exposed view model anyway.

deleted 8y ago

[deleted]