4 ms·

That's an unrelated problem, that's outside the scope of model presented. Remember the physicists adage: All models are wrong, some are useful. You can have yo

by Ygg2 4y ago

That's an unrelated problem, that's outside the scope of model presented. Remember the physicists adage: All models are wrong, some are useful. You can have your name change as well, or your calendar can change, or etc. Does that mean we stringly type everything? No. You model changes either via a separate field(s) or some kind of change table.

musingsole 4y ago
It's a very related problem. I agree: All models are wrong; some are useful. A string is a wrong model for an email address. But it's a pretty useful one. A custom type sitting lonely in an isolated codebase IS ALSO A WRONG MODEL. Arguably, it might be more a useful one than a string. But that's debatable. And on that debate, I'll argue a string is a better model because it is a better UNDERSTOOD model by more PEOPLE than whatever MyEmailClassForThisProject you just came up with.
- Ygg2 4y ago
  > It's a very related problem. It's not. You have the same problem regardless of type you place there. > A string is a wrong model for an email address. But it's a pretty useful one. Depends on use case. Perhaps it's an overkill in this toy example. I've real life use cases with untrusted user input where having raw string as untrusted and some kind of verified type as trusted would eliminate whole swath of errors.
mhaberl 4y ago
> You can have your name change as well, or your calendar can change What do you mean by that? Having a type for "country of origin" would mean that the type gives you limits on what values it can hold (any country known to ever exist) so you can not say something like: Country c = "Foo" because Foo is not a country. I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names. The calendar example I don't get. We already have "date" types in almost all languages so that "works", although it can be used as example of how hard is to implement some types. ----- So I say: >> This approach works good in some cases, but not always And you say: > Does that mean we stringly type everything? Come on now. "Not always" does not mean "Never"
- masklinn 4y ago
  > I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names. As always, that is very domain-specific: there are lots of countries with naming laws, some of which do have lists of legal names.
  - blep_ 4y ago
    Legitimate question: what do they do about immigration into those countries from countries without such laws?
    - masklinn 4y ago
      Likely nothing: usually they’re laws which apply to parents / birth certificates. I guess it’s possible that an immigrant trying to get naturalised would have to adopt a “legal” name for the country, but I’m not aware of any country where that’s a rule, aside from the Zairianisation movement of Mobutu.
- Ygg2 4y ago
  > What do you mean by that? I assumed the point was old name wasn't tracked and should be. > Having a type for "country of origin" would mean that the type gives you limits on what values it can hold No one said your type has to be completely set in stone and contain every valid value in advance. Have a trusted store of country name and valid until date. So defunct country can't be added.
- mostlylurks 4y ago
  Restricting the space of possible values is only one of the possible advantages of declaring a dedicated type for something. Even if it is not possible to restrict the space of possible values (e.g. with names, which can't realistically be restricted to any smaller subset than all possible strings), there are other advantages to having a dedicated type, such as preventing the user of the type from putting a value of that type into somewhere it doesn't belong, which is a very realistic scenario in stringly typed codebases, especially where there are similar but different sets of values, all stringly typed.

by Ygg2 4y ago

musingsole 4y ago

It's a very related problem. I agree: All models are wrong; some are useful. A string is a wrong model for an email address. But it's a pretty useful one. A custom type sitting lonely in an isolated codebase IS ALSO A WRONG MODEL. Arguably, it might be more a useful one than a string. But that's debatable. And on that debate, I'll argue a string is a better model because it is a better UNDERSTOOD model by more PEOPLE than whatever MyEmailClassForThisProject you just came up with.

Ygg2 4y ago
> It's a very related problem. It's not. You have the same problem regardless of type you place there. > A string is a wrong model for an email address. But it's a pretty useful one. Depends on use case. Perhaps it's an overkill in this toy example. I've real life use cases with untrusted user input where having raw string as untrusted and some kind of verified type as trusted would eliminate whole swath of errors.

mhaberl 4y ago

> You can have your name change as well, or your calendar can change What do you mean by that? Having a type for "country of origin" would mean that the type gives you limits on what values it can hold (any country known to ever exist) so you can not say something like: Country c = "Foo" because Foo is not a country. I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names. The calendar example I don't get. We already have "date" types in almost all languages so that "works", although it can be used as example of how hard is to implement some types. ----- So I say: >> This approach works good in some cases, but not always And you say: > Does that mean we stringly type everything? Come on now. "Not always" does not mean "Never"

masklinn 4y ago
> I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names. As always, that is very domain-specific: there are lots of countries with naming laws, some of which do have lists of legal names.
- blep_ 4y ago
  Legitimate question: what do they do about immigration into those countries from countries without such laws?
  - masklinn 4y ago
    Likely nothing: usually they’re laws which apply to parents / birth certificates. I guess it’s possible that an immigrant trying to get naturalised would have to adopt a “legal” name for the country, but I’m not aware of any country where that’s a rule, aside from the Zairianisation movement of Mobutu.
Ygg2 4y ago
> What do you mean by that? I assumed the point was old name wasn't tracked and should be. > Having a type for "country of origin" would mean that the type gives you limits on what values it can hold No one said your type has to be completely set in stone and contain every valid value in advance. Have a trusted store of country name and valid until date. So defunct country can't be added.
mostlylurks 4y ago
Restricting the space of possible values is only one of the possible advantages of declaring a dedicated type for something. Even if it is not possible to restrict the space of possible values (e.g. with names, which can't realistically be restricted to any smaller subset than all possible strings), there are other advantages to having a dedicated type, such as preventing the user of the type from putting a value of that type into somewhere it doesn't belong, which is a very realistic scenario in stringly typed codebases, especially where there are similar but different sets of values, all stringly typed.