5 ms·

This isn't a limitation of Swift, this is someone trying to write Objective-C in Swift. Let's say he gets what he wants - a distinct collection of instances th

by jcizzle 11y ago

This isn't a limitation of Swift, this is someone trying to write Objective-C in Swift. 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. The error message he is seeing about Self requirements is telling him this. That error message doesn't exist because Swift is having a hard time understanding the code, it exists because Swift understands that his code is wrong.

Manishearth 11y ago
While I mostly agree, there still should be a way in Swift to make a collection of virtual dispatch objects, including hash-based collections. But this can be done in a separate library since this isn't a language restriction. Might try to write one tomorrow, really.
- jcizzle 11y ago
  This is all possible - the issue is that you still must define equality if you want to put it in a collection that cares about equality.
  - Manishearth 11y ago
    Sure, and then you redefine it so that it can handle protocol objects (where a things of different concrete types are inequal). You may need a new Equatable/Hashable-esque protocol for this, but it should be doable.
nathanvanfleet 11y ago
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.
- 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).
voyou 11y ago
"What if a Twitter account and Hacker News account have the same id? According to this protocol, they are equal." Maybe that's the desired behaviour?

by jcizzle 11y ago

Manishearth 11y ago

While I mostly agree, there still should be a way in Swift to make a collection of virtual dispatch objects, including hash-based collections. But this can be done in a separate library since this isn't a language restriction. Might try to write one tomorrow, really.

jcizzle 11y ago
This is all possible - the issue is that you still must define equality if you want to put it in a collection that cares about equality.
- Manishearth 11y ago
  Sure, and then you redefine it so that it can handle protocol objects (where a things of different concrete types are inequal). You may need a new Equatable/Hashable-esque protocol for this, but it should be doable.

nathanvanfleet 11y ago

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.

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

voyou 11y ago

"What if a Twitter account and Hacker News account have the same id? According to this protocol, they are equal." Maybe that's the desired behaviour?