Add phone number input data type about carp.core-kotlin HOT 3 OPEN

Phone numbers

Storing/validating the country calling code separately seems appropriate. I'm uncertain why the ISO code for the country is there as well, though. It seems like this is superfluous information when it comes to the phone number.

The ISO country code could potentially be considered an alternative way to represent the same information, and the mapping of ISO 3166 to the calling code could be done at runtime (by hardcoding the mapping elsewhere in CARP core). However, this won't work since this doesn't seem to be a 1-to-1 mapping. The Dominican Republic uses multiple calling codes, as well as Puerto Rico.

ok - we can drop the ISO code.

For the actual number, I wouldn't store it as a string simply because it can be pretty-printed. The data format should be strict; if only numbers are allowed, only allow numbers (do verify that assumption, though!).

I think there are many numbers that are non-digits. For instance, you can type # and - in many speed dialing systems. For example, when calling a Zoom number or answering machine.

Informed consent

I suggest you make a separate issue for that, and keep this issue focused on phone numbers, so that the discussions can remain more focused.

I agree.

from carp.core-kotlin.

Phone numbers

Storing/validating the country calling code separately seems appropriate. I'm uncertain why the ISO code for the country is there as well, though. It seems like this is superfluous information when it comes to the phone number.

The ISO country code could potentially be considered an alternative way to represent the same information, and the mapping of ISO 3166 to the calling code could be done at runtime (by hardcoding the mapping elsewhere in CARP core). However, this won't work since this doesn't seem to be a 1-to-1 mapping. The Dominican Republic uses multiple calling codes, as well as Puerto Rico.

The ISO country code is likely relevant for other input data, such as the country of residence.

For the actual number, I wouldn't store it as a string simply because it can be pretty-printed. The data format should be strict; if only numbers are allowed, only allow numbers (do verify that assumption, though!). Allowing more flexible input is something which can be achieved by helper functions called by the UI. See MACAddress as an example which has a single strictly typed persisted value, but more flexible parse method for initialization.

Informed consent

I suggest you make a separate issue for that, and keep this issue focused on phone numbers, so that the discussions can remain more focused.

from carp.core-kotlin.

I split off the informed consent issue here.

from carp.core-kotlin.