Hacker News Reader

Comment by nathanvanfleet | Hacker News Reader

You're missing the point of what he's saying with a pretty dismissive statement. "Swift doesn't do that" is not a strong argument.

He specifically goes through why using protocols like that are a useful and powerful tool. He's making an argument about its usefulness and the ease of implementing it.

It is a really useful tool! It lets you show the commonalities and mask and private methods in classes. I would say that it would be a loss to not have this.

As for the "this might accidentally be seen as equal to something that is a different class" should not be a problem. In objective C isEqual implemented in a standard way is able to differentiate different classes from each other pretty much from the beginning of the method.

View on HN

Not saying Swift doesn't do that, saying he's doing it wrong. Protocols can still be interfaces (what he and you are describing), there is no loss. Two types that simply implement a similar protocol are by definition not necessarily equatable. The 'standard' way that Objective-C implements isEqual: is on a base class, which is a totally possible implementation in Swift as well.

That's the point he's making. He doesn't want a base class.

If you aren't lucky enough to have them be of the base class you have to create an empty template superclass just to satisfy the compiler. Objective-c has a better solution and things can dovetail without being in the same class.

"Doing it wrong" implies that Swift is just inherently better without making a real argument about why that would be the case. And the OP is actually making a pretty convincing argument that it isn't.

Swift is awesome at doing things better than obj-c and it really does reduce a lot of template code. But maybe not in this particular instance (right now).

He can't solve this problem without using a base class, so he wants to go back to Objective-C where he will use a base class? Objective-C does not have a better solution - it has the same solution here. The only difference is that ObjC will let you do what he is trying to do where the actual result is incorrect. That doesn't make Swift inherently better, it means he is wrong. OP is not making a convincing argument, and this isn't a point about Swift vs. ObjC. OP is just complaining because they don't understand what it is they are doing.

I don't think you understand what the parent is telling you at all.

It's clear from what they wrote that both the parent and the author of TFA know all that you described. The problem is not that they don't know these things or that they're "doing it wrong", it's that they disagree that the way Swift does is it's the better way, or in PL terms, the most expressive way.

>Let's say he gets what he wants - a distinct collection of instances that fulfill the 'Account' contract, but are different types. The approach so far is that to fulfill 'Account' by providing an accountID. That accountID is what indicates if two 'Account's are equal. What if a Twitter account and Hacker News account have the same id? According to this protocol, they are equal.

So? There's nothing wrong with that. If that's how he defines equality and not at the class level, that's what he should get. He should still be able to use a set with his definition of "equal" (which he could trivially change anyway).

Reply on news.ycombinator.com