5 ms·

> since the shared libs have generics and I'm always casting things. This indicates to me that you're trying to write code that isn't correct (not doesn't work

> since the shared libs have generics and I'm always casting things. This indicates to me that you're trying to write code that isn't correct (not doesn't work, but rather only works because of implicit couplings between components) and/or doing exotic lisp-style metaprogramming. In the latter case, yeah, C#'s type system isn't powerful enough. Others are (to an extent: arbitrary code execution at compile time is never going to be completely safe). In the former case ... that should be difficult. Forcing you to be explicit is half the point of a type system.

noduerme 4y ago
Casting is often necessary for parsing inbound data from certain mysql libraries or CSV or JSON depending on how it's written. I would guess that might be what the parent is talking about. That said, if you don't cast or parseFloat or whatever in JS you're going to have a lot of trouble. And if you're doing that, why not do it in Typescript where you'll know that the data you're accessing has been safely cast based on its type.
- xigoi 4y ago
  > Casting is often necessary for parsing inbound data from certain mysql libraries or CSV or JSON depending on how it's written. No, that's what sum types are for.
  - noduerme 4y ago
    I don't see how they're mutually exclusive. I use union types prior to typeguards to end up with ultimately checked, cast values. Say I have a boolean fetched from JSON as "1" or "0". By the time I expose it to the rest of the code as part of a Record, I want to change it to an actual boolean. At first I'm going to treat the inbound value as a union type, e.g. (String | Number | null | undefined | Error). After I deal with the error cases, I'm going to cast it (or in TS, reinitialize it as a single type, boolean) so that any code looking at the imported value sees it as definitely only a boolean without needing to have lots of different pieces of code run their own checks on its type.
    - xigoi 4y ago
      I wouldn't really call that casting, that's just narrowing based on control flow.
- deleted 4y ago
  [deleted]
suzzer99 4y ago
I mean casting to get mocks to work in unit tests, not live code. Probably there's a better way. I'm not a C# expert. But I was a Java dev for 10 years so it's not super unfamiliar.

noduerme 4y ago

Casting is often necessary for parsing inbound data from certain mysql libraries or CSV or JSON depending on how it's written. I would guess that might be what the parent is talking about. That said, if you don't cast or parseFloat or whatever in JS you're going to have a lot of trouble. And if you're doing that, why not do it in Typescript where you'll know that the data you're accessing has been safely cast based on its type.

xigoi 4y ago
> Casting is often necessary for parsing inbound data from certain mysql libraries or CSV or JSON depending on how it's written. No, that's what sum types are for.
- noduerme 4y ago
  I don't see how they're mutually exclusive. I use union types prior to typeguards to end up with ultimately checked, cast values. Say I have a boolean fetched from JSON as "1" or "0". By the time I expose it to the rest of the code as part of a Record, I want to change it to an actual boolean. At first I'm going to treat the inbound value as a union type, e.g. (String | Number | null | undefined | Error). After I deal with the error cases, I'm going to cast it (or in TS, reinitialize it as a single type, boolean) so that any code looking at the imported value sees it as definitely only a boolean without needing to have lots of different pieces of code run their own checks on its type.
  - xigoi 4y ago
    I wouldn't really call that casting, that's just narrowing based on control flow.
deleted 4y ago
[deleted]

suzzer99 4y ago

I mean casting to get mocks to work in unit tests, not live code. Probably there's a better way. I'm not a C# expert. But I was a Java dev for 10 years so it's not super unfamiliar.