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.
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"
As always, that is very domain-specific: there are lots of countries with naming laws, some of which do have lists of legal names.
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.
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.
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.
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.