“SwiftData inheritance relationship”

>> Why would the standard library not include something simpler like this?Of course, I don't know, but I have a possible explanation that I replay to myself whenever I start cursing at String's awkward syntax.The explanation is historical. The class NSString is jam-packed with useful functionality, but it's always been weird that the cananical underlying data representation is UTF-16. UTF-16 is fine, but there's plenty of stuff stored as UTF-8, and even now plenty of sources of pure 8-bit character arrays. This means that there are are lots of actual data conversions to and from UTF-16. (At the time NSString adopted UTF-16, around 1990, the text world was quite different. At that time, it looked like 16-bit units for text would obviously win over 8-bit units — wchar clobbers char, photos at 11!. UTF-16 seemed like the forward-looking option, and UTF-8 looked like a compatibibility footnote. Obviously, that's not what happened.)In practice, concrete subclasses of NSString may actually store data in forms

Thank you, I was wondering if it was an inherited property of something that I wasn't inheriting or what.

Sure, but this avoids the problem by further specializing the protocol. On the most basic level, I just want the protocol to define the relationships. Ideally, I could create any number of variations on TypeB that add different kind of specialization, without breaking the relationship between TypeA and TypeB.

I'm not sure what you mean. Protocols are not superclasses. Protocols dictate a set of things that can be guaranteed about any type that conforms to them.So if your protocol is empty, then it doesn't require anything from types that conform to it. And the only thing the compiler can know about all the types that conforms to it is that they conform to it, nothing more. So It can't know of any methods or properties or typealiases of that type, unless it is looking at the concrete type and not the protocol, of course.The only thing it means for a (concrete) type to conform to a protocol is that it has to conform to it, it has to provide implementations for the methods, properties and typealiases that the protocol demands, or it will fail to conform.There's no inheritance or anything like that going on, a protocol and the types conforming to it cannot reach each other in any way. The protocol specifies an interface that the conforming types must have and thus are guaranteed to have, that's it.And a type

Well, one of the proposals of the Protocol-Oriented Programming talk seemed to be suggesting that we could treat them (somewhat) synonymously to superclasses. Besides, I don't want these relationships to be limited to classes - I'd like the freedom to use structs, for example (as in my sample problem). (By the way, the fact that TypeB was empty wasn't intended to be significant.)

I saw the Protocol-Oriented talk and I thought it was one of the best talks. I think protocols are great and I use them and value types for most things, sometimes a class is needed for the indirection / identity, but I almost never use class inheritance, so in that way I guess that you can say that using protocols can do away with super classes.However, I can't really understand how you see protocols, what they are and what expectations you have on them, and this makes it hard to explain what they are and what they are not. (I did try in my previous reply.)I would suggest that you read more about protocols and generics in the Swift book.One of the most important differences between Objective-C and Swift is that in Objective-C almost everything you do is done dynamically, while in Swift and especially when using protocols, you tend to not do dynamically what can be done statically, which means you will want to make the compiler know as much as possible about your types and your code, which is totally

Well, I'm starting to think that I probably see protocols exactly as they are, but just hoped for some unforeseen magic!What I'd hoped to do was not necessarily to create superclasses, per se, but to create a set of relationships between objects (types, really). Specifically, I'm working on a VIPER variant for our new project, and I wanted to use protocols to specify the relationships between components in each module. This would be pure abstraction, in the sense that there would be no implementations at all, just relationships (so, perfect for protocols). For example, a Presenter might know that it has a FlowController, without knowing anything else about it. This would be implemented at the protocol level. The components would adopt these basic protocols, which would enforce a certain connectivity between components, but the objects conforming to the protocols (the actual implementations) would define their own functionality, given the particular module (use-case). I can't do this

The point was to separate the architecture from its implementation. As far as compilation goes, I do explicitly pass sTypeA an instance of structTypeB, so I don't see it as being particularly ambiguous at compile time.As far as the empty TypeB goes, as I said before, this is just a mock example; it would likely have some more specific requirements (but that's beside the point).In the actual implementation I'm trying to figure out, TypeA might be an Interactor (i.e., in VIPER), and TypeB might be a Presenter. If I have two use-cases, like UserCreation and TaskCreation, say, then I would create a UserCreationInteractor: Interactor, and a UserCreationPresenter: Presenter. Thus the protocol would (at minimum) specify the relationship between UserCreationInteractor and UserCreationPresenter (i.e., fundamentally the same as Interactor to Presenter). Crucially, the actual implementation of UserCreationInteractor and TaskCreationInteractor would likely be quite different.