5 ms·

Not only that, it implies that there must be a valid null-state for every type, which is also a bad idea.

• jackcviers3 6y ago
  No, it implies that there must be a generic two-valued datatype to wrap every state: Just t | None You can have your null case, and avoid the null-pointer exception, default keyword, chained ? null-check hellscape in which we currently reside.
• sullyj3 6y ago
  I'm not entirely sure what you're getting at here. Are you saying the author is arguing a call like new Customer() should return something valid? I think the FP way would be to disallow constructor overloads with no arguments, as really, there's no reasonable thing to be done here. If you don't have all the necessary information to initialize a customer yet, you don't get to initialize one, and you pass around a partially applied constructor function instead. ie, The argument is that (in pseudocode): Customer(name = "Jimmy", address = null) is not really a customer if address is a necessary piece of information, so we should distinguish at the type level by passing around a function that takes the address and returns the correctly initialized Customer like so \addr -> Customer(name = "Jimmy", address = addr) Admittedly, this prevents you from accessing name until you provide an address, but I don't think there are many valid use cases where you want to access data before the Customer value is corrrectly initialized. I'd consider this a code smell to be refactored.
  • learc83 6y ago
    > Admittedly, this prevents you from accessing name until you provide an address, but I don't think there are many valid use cases where you want to access data before the Customer value is corrrectly initialized. I'd consider this a code smell to be refactored. If you really needed to do that you could just define a partial customer with no address field and pass are that around.
• lmm 6y ago
  No it doesn't; the whole point is to avoid every type having a null state. You only define null states for those types for which it's semantically valid. For most types, you just don't have a null state and don't allow them to be constructed in an invalid state.
• dudul 6y ago
  No, it implies that you can use your type system to surface the fact that a variable may have no values.