4 ms·

Maybe they did, got confused and gave up. How would you deal with 4, 11, 12+13, 14 and 18 here?

by lvass 4y ago

soco 4y ago
Quite simple: you don't deal at all. That's zero assumptions about the name. Let them eat cake and enter whatever they want. The user should know their sweetie well enough to guess what they will enter as own name. This is an assumption about their level of mutual knowledge, true, but not one about the naming scheme.
- lvass 4y ago
  This is a design decision that will very likely lead to missed matches, bold of you to assume it's desirable but even that doesn't answer the entire ordeal. How are they going to enter the name, have you read 11?
- not2b 4y ago
  On the contrary, there is a very strong and completely invalid assumption: that Alice will type her name in exactly the way Bob typed her name, and vice versa, that neither will misspell it, that either both will use the official name or both will use the same nickname.
kube-system 4y ago
> 4. People have, at this point in time, one full name which they go by. The relationship between person and name is one-to-many > 11. People’s names are all mapped in Unicode code points. You can implement custom characters, i.e. https://en.wikipedia.org/wiki/Private_Use_Areas https://en.wikipedia.org/wiki/Private_Use_Areas or have a process for exceptions > 12. People’s names are case sensitive. 13. People’s names are case insensitive. You can store this as an attribute > 14. People’s names sometimes have prefixes or suffixes, but you can safely ignore those. This can be other fields if you're trying to structure the data, or you can simply store the entire name as a contiguous field. > 18. People’s names have an order to them. Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name. Don't string compare names as a test for equality. The obvious response to this is: that's too hard (/impossible to do). But that's just the reality of the situation. These issues are not necessarily possible to solve. #21 in particular makes this application very broken even with very plain vanilla western names.

Maybe they did, got confused and gave up. How would you deal with 4, 11, 12+13, 14 and 18 here?

by lvass 4y ago

Maybe they did, got confused and gave up. How would you deal with 4, 11, 12+13, 14 and 18 here?

soco 4y ago

Quite simple: you don't deal at all. That's zero assumptions about the name. Let them eat cake and enter whatever they want. The user should know their sweetie well enough to guess what they will enter as own name. This is an assumption about their level of mutual knowledge, true, but not one about the naming scheme.

lvass 4y ago
This is a design decision that will very likely lead to missed matches, bold of you to assume it's desirable but even that doesn't answer the entire ordeal. How are they going to enter the name, have you read 11?
not2b 4y ago
On the contrary, there is a very strong and completely invalid assumption: that Alice will type her name in exactly the way Bob typed her name, and vice versa, that neither will misspell it, that either both will use the official name or both will use the same nickname.

kube-system 4y ago

> 4. People have, at this point in time, one full name which they go by. The relationship between person and name is one-to-many > 11. People’s names are all mapped in Unicode code points. You can implement custom characters, i.e. https://en.wikipedia.org/wiki/Private_Use_Areas https://en.wikipedia.org/wiki/Private_Use_Areas or have a process for exceptions > 12. People’s names are case sensitive. 13. People’s names are case insensitive. You can store this as an attribute > 14. People’s names sometimes have prefixes or suffixes, but you can safely ignore those. This can be other fields if you're trying to structure the data, or you can simply store the entire name as a contiguous field. > 18. People’s names have an order to them. Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name. Don't string compare names as a test for equality. The obvious response to this is: that's too hard (/impossible to do). But that's just the reality of the situation. These issues are not necessarily possible to solve. #21 in particular makes this application very broken even with very plain vanilla western names.