At first glance this looked like a code smell, but after some reflection I can't think of a cleaner, more readable way to uniquely identify each possible relationship -- especially in a strongly-typed language with an IDE.
You need an intermediate representation (like a tree) rather than attempt to brute force every possible permutation up until some arbitrary point. Even if that weren't the case, it'd be better to give it a more obscure name or create some kind of naming system and then document it rather than demonstrate why self-documenting code can become self-defeating if taken to an extreme.
The issue of a tree is you could trivially create nonsensical relationships. An alternative would be some sort of nested attributes / tag set but even that's not excellent.
Why would an obscure name be better? This looks like an example where a very specific relationship is needed, and the name specifies precisely what that is. Choosing an obscure name for this feels like an attempt to hide the fact that this is a special case by using vague terminology.
Trees can't be used for relationships, due to the crazy things that people can do with each other. You'll need a DAG, and you'll need to detect cycles.
A pretty idiomatic (and trivial to implement) Scala way of doing this would be to have a DSL with a name for each relation and compose them together using function application. So to express "MothersSiblingsDaughter" you'd write "mother sibling daughter". The whole expression would return an object which contains a linked list of the individual components, consed together by each individual function application in the chain.
Of course, this is kind of co-opting the call stack to build up at runtime what the compiler can already provide as an AST, so it might be better to just use a macro.
This representation can't be serialized quite as easily as a single symbol or whatever Apple is doing, but it is infinitely flexible. And it seems like a code smell to me that they have a special case for the father's brother, while the mother only has a generic "sibling." It should be up to the view layer to determine that kind of localization-specific logic. If you just store a completely arbitrary relation then you can punt it to the localization to decide how to translate that into meatspeak.
I still don’t think this is a good solution because of the common CNLabelContactRelation prefix. It would be better to introduce a CNLabelContactRelation enum? Then the enum cases would be much less painful. Or at least an empty enum as a namespace:
enum CNLabelContactRelation {
static let aunt = "…"
static let auntFathersBrothersWife = "…"
}
Why on earth would someone do bug fixes for free for a corporation that has cash reserves of $250 billion but is too stingy to pay for quality control?
But by fixing it yourself, aren't you effectively training the corporation to stay sloppy? Sure, this bug is fixed right now. But a year down the road, when the staff count for quality assurance gets renegotiated, the position to deliver quality out of the box gets weakened, resulting in even more bugs of this kind.
> Are you saying that no-one should report anything because it encourages them to let bugs slide into production?
No, of course not :) That would indeed be absurd. What I meant was this particular case. Apple of all companies is by no means incapable of hiring people to deliver quality. They make billions upon billions by avoiding taxes[0] and shifting production to deleloping countries [1]. If a company like this learns that it can externalize QA even more, they will do so. We are not talking about social contract like situtions here, this isn't open source software.
Apple's bread-and-butter is products. To the extent that they shift their focus from their products, they jeopardize profits and every other measure of business success.
Good QA is part of being focused on products. So our response (or lack of response) to glitches like this in their software is very unlikely to affect their overall approach. Either they're product-focused or not: if they are, they'll be profitable and QA will be good. If not, they'll eventually fade away anyway.
... All to say, if you want to see issues like this fixed, I suggest reporting them and not worrying about it.
I can see why this is needed. English has very broad words for relatives like "grandfather" or "aunt". Most languages have more specific words, especially Chinese where there are separate words for fathers or mothers side, older or younger and sibling or siblings spouse. You also often use these relation words rather than their names when referring to a relatives. If this code was in Chinese, they would all be short words.
English words like "aunt" cannot really be translated into Chinese. If you are translating a book you either try to figure out the exact relation from the context, or just pick one if it doesn't matter. In someones address book you can't do that.
I read a book where this difference in expressiveness removed a subtlety of writing from the translated version.
The original English version had a passage where it was unclear (on purpose) which grandmother was being referred to (it later turned out to be the one you didn't expect). However, with Swedish having no generic word for grandmother (only mormor and farmor), this nuance was lost in the translation.
In Vietnamese there are at least 4 different relationships that we call "uncle" (father's/mother's older/younger brother) in English! I have no idea how you refer to cousins. My teacher told me when he visits family he often doesn't know the word for his own relationships. Apple trying to capture a complete multilingual kinship lexicon sounds like an impossible task, I guess they must be focussing on specific languages here (Chinese is a good bet).
Genuinely curious, but is it actually like that in most languages? I wondered if it was maybe an East/West difference, since I haven't come across that in my French & German learning, and I didn't think Dutch or Danish were like that either. But apparently Swedish does have this (eg faster/moster for paternal aunt & maternal aunt)?
(Most of my learning is via Duolingo, so I'm no expert, just curious.)
Didn't even English have a bunch of words that were lost as time went by?
We do have quite a few words in Lithuanian (e.g. for maternal/paternal branches and more detailed words for "X in law"). But it was getting simplified in the past few decades. I've heard quite a few words that I couldn't describe without looking at the dictionary.
Modern Russian has no difference between paternal/maternal aunt/uncle (though there are apparently archaic forms that denote the difference that no one uses).
On the other hand, it has different words for "wife's mother" and "husband's mother", which in English are both "mother-in-law". Similar for the "father-in-law" relationship: different words for "wife's father" and "husband's father". Similar for sibling-in-law relationships.
(Of course there's the open question of whether Russian would count as "East" or "West".)
Sweden has it, at least for aunts/uncles, and grandparents (and great grandparents, and great-great-grandparents...).
For aunts its faster/moster (portmanteau of father-sister, mother-sister, roughly). For uncles its farbror/morbror (lit. father-brother, mother-brother).
For grandparents its farfar/morfar (father-father, mother-father) and farmor/mormor (father-mother, mother-mother).
A great grandparent could be e.g. a farfarsfar, or father-fathers-father.
Is there a notion in linguistics of languages being more "modular", i.e. tacking on details like this through additional words, versus having more and more specific words to cover these cases?
Coming from my native German, I am very much used to the former, so I always find it interesting to see how different other languages are structured sometimes.
Not quite the same thing, but languages (like German) that build up words for complex concepts by forming big words out of little ones are called agglutinative[1].
German is not considered an agglutinative language (you can google it if you don't believe me). German has long compound nouns, which isn't really the same thing.
English has long compound nouns too, by the way. You can make basically arbitrarily long nouns like "chief regional dairy inspector" in English. In German you would write this without spaces between the words. That's just a typographical convention, not a linguistic difference. It doesn't mean German's structure is fundamentally different from English's, and isn't what linguists mean by "agglutination".
If I recall correctly from my very limited knowledge, German is not really agglutinative, as it mainly just has the ability to combine preexisting nouns together into one word, while agglutinative languages take a root and then add a pre- and suffixes to build up new words related to the meaning of the root.
Taking the 7th example from this table [1], while you could theoretically construct something like "erfolglosenmacherwerden" in German and have it still sound somewhat comprehensible, that is not something that is actively done in the usage of the language and would sound about as strange as coming up with "to unsuccessfulmakerbecome" in English.
It’s a bit anglocentrists to never think that ”oh maybe there are other systems where it makes sense.” Hell, _most_ languages have more words for kinship than English! I always found it odd for example that grandfather doesn’t specify on which side. Like, how is that not super useful information?
Try making a five year old say ”maternal grandfather,” other languages have two-syllable words for all of these, like the Chinese words for which these are made.
You say Maternal/Paternal Grandparents, or add last names, or use different names (eg Granny and Nana). I can't think of a situation where I've had to differentiate them as relatives, only as individuals, so I can't see a distinction being that useful.
Really, you’re going to defend this lack of precision? I’m sure you can get by but having precise words is rarely a loss. Anglocentric superiority complex eh.
I disagree that calling out anglocentrism is a "personal swipe," it is relevant to the argument (i.e. that it is hard to see beyond your biases.) Discussion should surely not be stymied for the sake of civility, better we step on each other's toes and get our point across than sit in our respective corners and sulk.
I'm sure there was a better way to say what I said, but it was not mean-spirited as I am sure you can see.
You're right that I'm stuck in the Matrix so to speak, so I may well be missing out on something I'm not aware of. But I don't believe I've ever had to use the words 'Maternal/Paternal GrandMother/Father/Parent' which must say something about how often its used.
Maybe we could turn it around, maybe you only use the word because it exists, maybe its like defenestrate. We could get by perfectly well without it.
I don't believe I expressed on opinion on whether any one language was 'better', I could wax lyrical about the warts and shortcomings of the English language, I don't know enough about any other languages to say whether they are better or worse.
表姐 means older female cousin of a different surname. If surnames are always passed down via the father that implies an elder cousin who is either your mother’s sibling’s daughter or your father’s sister’s daughter.
It's still a specific relationship in chinese kinship, which is likely why it was included as apparently CNf statically encodes all possible relationships.
And, in fact, CN has never referred to Chinese - it's an ISO two letter country code abbreviation for the PRC, admittedly - but the ISO two letter language code would be ZH for the Chinese language.
In case you're serious I'd have to rely on IDE completion or copy/paste to input this, not being familiar with chinese input methods. It would also make it trickier to compare identifiers and make sure that it makes sense.
I think it makes more sense to keep all identifiers in English or alternatively provide completely localized versions of the API in other languages, going halfway is just going to confuse everybody. Remember for instance the confusion created by PHP using hebrew in the symbol for the '::' operator: https://stackoverflow.com/questions/592322/php-expects-t-paa...
I am genuinely curious why not. Interesting to know that history about php!
A middle ground might have been to use a transliteration such as CNContactLabelRelationBiaoJie.
Your point about input makes sense in that it's technically possible to type the English identifier without Chinese input methods, although I would be surprised if anybody typed that long-ass English identifier without IDE completion or copy-paste either!
The point about being able to more easily compare, I disagree with - the long identifiers are hard to check.
IMO if an API exposes an uncommonly-known but well-defined concept, I think it's acceptable, and better, to ask users of the API to learn the concept before use rather than paraphrase it.
It better matches what developers are likely going to try to do: if anyone is ever going to write a program that has to care about this case, I'm pretty sure the spec isn't going to be something like "if the contact is the user's elder female cousin who is either the user's mother's sibling's daughter or the user's father's sister's daughter..." - it's likely going to say, if not in Chinese, "if the contact is the user's 'biaojie'..."
There is good precedent for this kind of preference for expressing concepts that aren't broadly familiar in technical APIs. You'll get some symbols containing words like AffineTransform or CMYK in it, and probably many programmers wouldn't know what they stand for either until they need to learn what they are, but that's ok and better than dumbing down the API to something like RotationOrTranslationOrResizingOrCombinationThereOf or PrimarySubtractiveColorSystem.
> In case you're serious I'd have to rely on IDE completion or copy/paste to input this, not being familiar with chinese input methods. It would also make it trickier to compare identifiers and make sure that it makes sense.
I'm not sure it's easier with the super-large English name
They could have used Pinyin. Even people who don’t speak Chinese and have to look it up would have an easier time understanding it than trying to parse this identifier.
When I put this in Google Translate, it auto-detects Japanese and gives me "outer cover." When I specify Chinese, it just says "cousin." So it's not trivial to look up.
Presumably you would google "CNBiaoJie" and find Apple documentation explaining the concept.
(As an aside, Google Translate is a terrible way to look up the definitions of specific words. It is not a Chinese-English dictionary and doesn't try to be. Wiktionary would be a much better free option.)
And then every time you re-read the code you have to look it up to understand 1/ what the hell is even this and 2/ is it the right one at the right place.
Yes, which I think is easier than having to parse and understand this identifier every time you see it.
Especially since after a few times you will remember what it means and not have to look it up anymore. There's a good reason we use jargon for complicated concepts rather than re-explaining them every time they're used. "while" is a lot easier to understand once its meaning has been explained to you than "EveryTimeWeGetHereCheckIfThisConditionIsTrueAndExecuteThisCodeBlockAndJumpBackHereIfSo".
Whereas with this English symbol that might not fit on a screen, there are none of those problems?! If the concept is foreign to you to begin with, but you have to care about it for some reason, you're going to have a bad time with either 1 or 2 no matter what the symbol is. (Though I agree that transliterating to BiaoJie would make it easier.)
I'm assuming those Mandarin characters comprise the word for that relationship? I was wondering why this existed and I thought maybe they were adding the Hindi words for specific relatives (there's many, I assume the same is true for Mandarin).
Mandarin is a spoken language. The characters are "Simplified Chinese" in this case. The characters will sound different read in different languages.
e.g. the two Traditional Chinese characters 東京 translate roughly to "Eastern Capital" and are read dōngjīng, while they are also valid Japanese Kanji where they have the same meaning and are read as Tokyo. (Yes, the name of the capital of Japan.) Interestingly, Běijīng and Nánjīng similarly mean "northern" and "southern" capital respectively.
There was once an Eastern Capital in China which is also named as Kaifeng, the capital of the Northen Song Dynasty. It is to east of Chang'an, which is now Xi'an, and the capital of most of earlier dynasties.
In Chinese culture, your male line ancestry matter more. Your mother's family is considered auxiliary ('外家'), thus only your father's brother's children are considered in the same family, and these cousins are labeled “堂”, all the other cousins are labeled "表”, and "姐" means older sister.
That's my understanding, a difference is made between paternal lineages (through the father's brothers) and maternal (either father's sister or any sibling of the mother).
Possibly denoting similar v different family names?
HyperTalk and AppleScript. And I think in old versions of Visual Basic it was common to use 1-based arrays (although you could set the range to anything)
For a long time, the Carbon universal headers
Included a plain, non-namespaced (c header) MacTypes.h which included:
enum {
h = 0,
v = 1
};
This could lead to very confusing compiler errors... it was there for compatibility with an anonymous pascalnunion that let you treat a pascal Rect as an anonymous array of two Point structures..
Well, there's CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter, which is two letters longer than CNLabelContactRelationElderCousinMothersSiblingsDaughterOrFathersSistersDaughter.
I'm grateful that Apple at least prefixed this. IIRC, between iOS 11 and 12, Apple added a Contact class somewhere within their standard set of frameworks. I was maintaining an app that used CoreData as a store and did not have prefixed Core Data entity names. And of course it had its own Contact class.
Long story short, I started building against the newer SDK and the app started crashing in the most oblique way possible. Prefixing the entity and class name solved the problem, but I only stumbled on that through a combination of luck, intuition, and half a day of banging my head against a wall.
It's not about the "CN" bit. People are talking about why the variable exists at all. Essentially the reason being ventured is that that relationship has a specific name and meaning in Chinese with no English equivalent beyond an exacting familial definition. Imagine trying to express "grandfather" in a language that doesn't have the concept. You might end up with "father's father."
(I know nothing about Chinese. Just reporting what's been said elsewhere.)
> Imagine trying to express "grandfather" in a language that doesn't have the concept.
Or, for a more concrete example: "daughter-in-law". Many of the English "-in-law" relations may seem foreign to cultures with different conceptions of the extended family.
Your younger cousin sister, either from one of your mother's brothers and sisters, or from one of your father's sisters.
Or two characters in Chinese: 表妹(BiaoMei). If she is from one of your father's brothers, she's your 堂妹(TangMei). The latter is regarded as being closer because you share the same family name, but nowadays it just doesn't matter any more.
Some of the other commenters think it's 表姐. No matter who is right, you see, the long name bears no clear meaning even for Chinese.
The other commenters are saying 表姐 because it was originally "Elder", not "Younger". The moderators decided to change it and break all the discussions.
HN already supports title edits, so it's simpler than changing the CSS, and it's easier to read because the breaking is on the internal word boundaries. Here's the title with the zero-width spaces added:
Then the title would not make sense anymore. Adding a simple css rule would also be futureproof, because i’m quite sure this is not going to be the last time an absurdly long title word appears.
Does this page have some sort of camel-case aware word breaking? As I resize the page I notice it always remains broken at a word boundary and never breaks inside a word.
Ok, I see it now: there are wbr tags between the words on the page. TIL.
Anybody care to introduce me to this? Why does it have to be father's sister but mother's sibling? And how does elder and younger cousins behave differently?
* in many EA and SEA culture, there's a difference made based on the age differential aka different term of address to people older than you v younger than you, also gender
* chinese (and likely others) also make a difference between patrilineal relationships and matrilineal, so there's a term of address for people related through the father's brother (and thus sharing your family name) versus other parent's sibling (not sharing your family name).
The combination of the two yields what you have above:
* cousins through your father's brother (sharing family name) are 堂 (táng) all others are 表 (biǎo)
* older brother is 兄 (xiōng), younger brother is 弟 (dì), elder sister is 姊 (zǐ) and younger sister is 妹 (mèi)
Therefore an older "sister" (same generational rank) through an other line than your father brothers would be 表姊 (biǎozǐ).
I am pretty sure it is because in some languages (such as Arabic), there are specific, different words for relatives in those different cases. Someone more knowledgable than I can probably confirm.
I have no idea what "BiaoJie" is (well, in context, I assume it's a romanization of the pronunciation of 表姐), so that name would be completely unhelpful. Whereas the current name describes the relationship such that I can understand it, even if I don't know why this particular relationship is deserving of a name.
Something like CNBiaoJie also assumes that Chinese is the only language that names this relationship, and I don't know if that's true.
I have no idea what ElderCousinMothersSiblingsDaughterOrFathersSistersDaughter is, and understanding and remembering "BiaoJie" would be much easier for me than re-parsing that every time. As I pointed out in another comment, there's a reason we give short names to complicated concepts instead of spelling them out every time. "while" is a lot easier to understand once its meaning has been explained to you than "EveryTimeWeGetHereCheckIfThisConditionIsTrueAndExecuteThisCodeBlockAndJumpBackHereIfSo".
> Something like CNBiaoJie also assumes that Chinese is the only language that names this relationship, and I don't know if that's true.
No it doesn't, not any more than having an identifier called "Sister" assumes that English is the only language with the concept of sisters.
It’s kind of nice seeing the homepage with a fixed row height per story! I guess it will not last bit that was a nice thing that came of this. Thanks, OP :)
This is a joke right? Please explain if not. Why wouldn’t you just name the variable relationship (or CNRelationship to adhere to nonsensical globals) and abstract the method for getting there to other logic?
In principle yes, but I tried in 4 (edit: 5) browsers and couldn't reproduce the problem, and it's late here and I'm running out of steam. So you may have to suffer overnight. Sorry about that.
Edit: ok, thanks to https://en.wikipedia.org/wiki/Unicode_character_property#Whi... I put in a bunch of ​. I hope that fixes it because I need to sign off now. If it isn't fixed, it would be helpful if someone would email hn@ycombinator.com so we see that in the morning. Short term memory does not survive the firehose.
Happened for me on iOS 13 if it helps. Font stays the normal size but you have to scroll right. If you zoom out, it’s a bit harder to read but not bad.
HN should add the CSS rule "word-wrap:break-word". In fact this rule should almost always be the default for text that might contain excessively long words (such as user-submitted text on forums).
Here's the full list: https://developer.apple.com/documentation/contacts/contacts_...