4 ms·

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 th

by jcizzle 11y ago

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.

nathanvanfleet 11y ago
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).
- jcizzle 11y ago
  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.
  - coldtea 11y ago
    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).

by jcizzle 11y ago

nathanvanfleet 11y ago

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

jcizzle 11y ago
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.
- coldtea 11y ago
  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).