Hacker News Reader

Comment by TimTheTinker | Hacker News Reader

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.

Here's the full list: https://developer.apple.com/documentation/contacts/contacts_...

View on HN

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.

A second issue is, this is probably a localisation / cultural concern: below, yorwba notes that this relationship is a specific term in chinese kinship: https://en.wikipedia.org/wiki/Chinese_kinship#Common_extende....

And generate the list using metaprogramming at compile time.

Not sure, but I sort of expected this monstrosity happens because the labels are intended to be localizable.

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.

https://stackoverflow.com/questions/6163683/cycles-in-family...

Here's the likely explanation for these: https://en.wikipedia.org/wiki/Chinese_kinship#Common_extende...

And video version: The Complicated Chinese Family Tree [https://www.youtube.com/watch?v=nCFRoILS1jY]

And an online calculator to try: http://tool.bm8.com.cn/kinswoman/

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.

As noted elsewhere, this is more than likely for localization which composing would not enable. Would also explain the asymmetry, does it match Chinese? https://en.m.wikipedia.org/wiki/Chinese_kinship#Common_exten...

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 = "…"
  }

In Objective-C (and C), enum members are unscoped. So in your example "aunt" would be in the global namespace.

`Colleague` in `CNLabelContactRelationColleauge` is spelled incorrectly.

If you have a macOS or iOS beta installed, please report that through the Feedback app on either?

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?

Because otherwise thousands of developers will have to see that typo for the next ten years.

Like "Referer" :-) https://en.wikipedia.org/wiki/HTTP_referer#Etymology

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.

This is slightly absurd. It's reporting a very minor bug, not offering to implement a whole feature.

Are you saying that no-one should report anything because it encourages them to let bugs slide into production?

> 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.

[0] = https://itep.org/fact-sheet-apple-and-tax-avoidance/

[1] = https://www.theverge.com/2019/6/28/19102703/apple-mac-pro-ch...

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.

No.

But at the same time you can't really admonish someone for not doing something you won't do either.

Would it not be better to just allow the user to label the relation the way they want and only give options for some most common(important?) ones ?

Amen. Sometimes it takes what it takes to be precise.

Reply on news.ycombinator.com