“SwiftData inheritance relationship”

Thanks, that makes sense (unless somebody has a good explanation for why extensions with constraints cannot have an inheritance/conformance clause, neither now nor in the future) .

I wonder if I could read your intension, but have you tried this?class CritterAgent: GKAgent2D, GKAgentDelegate { var scene: SKScene! init(gameScene: SKScene) { self.scene = gameScene super.init() } //... }Defining non-convenience initializer suppresses inheritance of designated initializers.

The setValue(forKey:) and valueForKey() methods are actually part of objective-C's key/value observing functionality which are inherited from NSObject, and not part of the NSUserDefaults methods for storing and retrieving values.

Have you tried using the @objc() attribute to set the name in the objective-C runtime?https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithObjective-CAPIs.html#//apple_ref/doc/uid/TP40014216-CH4-XID_36@objc(XYZTestClass) class TestClass { / ... */ }It should prevent the class from being tied to the different namespace of the Swift modules in the local and remote code.Also, you might need your class to inherit from NSObject if it doesn't already, since NSXPCInterface wants a Set<NSObject> parameter and might use the NSObject base class methods.

I think the replies you're getting are a little bit harsh, but there are some larger issues to think about:1. At least in your original example, you wanted protocols that differed only in the type on which they were based. In spite of recent enhancements, protocols are really about behavior, and it's at best questionable whether your various ValueProviders have different behavior when they just operate on different types. In a way, it's exactly the point of Swift protocols that the type represented by your ValueType typealias isn't part of the ValueProvider behavior.2. There's an issue about the difference between generics (as in Swift), versus templates (as in C++). I think this has been discussed in the forums several times in the past. In a way, you're asking for a ValueProvider template, not a ValueProvider protocol.3. As well as trying to define conformance, in your scenario you are also trying to implement something like inheritance for ValueProvider. It may be that the correct solution is to m

Thanks Quincey :-)(1) Ok, I can understand this angle of reasoning. Jonhull's suggestion of declaring separate ValueProvideDouble, ValueProviderInt, ValueProviderString protocols would then be the most Swift-like solution. Hopefully we can all agree that declaring a bunch of protocols like that looks like code smell and a potential candidate for language-level solution or deeper refactoring of the code.(2) This might be the case, although I do not have experience with C++ templates. However, as I wrote above, C# and Java have equivalents of generic protocols/interfaces.(3) As you correctly pointed out, this can be done in Swift using classes. Instead of the generic protocol, I can use a generic superclass (which Swift supports) and it will work just as I want it to.Unfortunately, I also need value semantics, which is why I'm trying to do this with structs.Also, there is a subtle issue - I don't really need the implementation inheritance. The superclass would have empty implementation, which is usuall

Ah, nuts, got pulled away from my iOS 9 work and missed your response. Still trying to come up with the best way to track the new dev forums.I'm working on a social sharing app that lets you have relationships with other people (shocking, I know) and I wanted to make various relationships searchable - enter somebody's name into Spotlight and have that result take you directly to the detail view in the app that displays your relationship with that person. If you choose to sever the relationship with that person, I want to remove them from the search index. My original implementation was creating the NSUA when the user navigated to a distinct relationship view.My theory was you'd be more interested in seeing you old college friend Jane, who you interract with regularly, than Jane, your second cousin twice removed who you don't really like but can't de-friend because, well, family. I realize I could be attempting to recreate the smarts that you folks have already buil

I'm working on a social sharing app that lets you have relationships with other people (shocking, I know) and I wanted to make various relationships searchable - enter somebody's name into Spotlight and have that result take you directly to the detail view in the app that displays your relationship with that person. If you choose to sever the relationship with that person, I want to remove them from the search index. My original implementation was creating the NSUA when the user navigated to a distinct relationship view.I think what you should do is use CoreSpotlight to index the relationship/person information, and then use NSUA to layer on top of that the additional information about how the user navigates those relationships. A couple points to consider:Using CoreSpotlight will allow you to index all the relationships a user has established regardless of whether they have viewed them in your app. If you didn't do this, users wouldn't b

Did you have any specific questions about the contents of the Core Data Model Versioning and Data Migration Programming Guide?It sounds like you're pretty much going to be locked into the three stage migration process, and you're going to be needing to do work in step 2:Recreate relationships.At the beginning of this phase, the entity migration policy is sent a createRelationshipsForDestinationInstance:entityMapping:manager:error: message; at the end it is sent a endRelationshipCreationForEntityMapping:manager:error: message.For each entity mapping (in order), for each destination instance created in the first step any relationships are recreated.

Protocols with self or associated type constraints (like Equatable) are not dynamic at all. They are fully compile-time determined based on the static type. The downside is that they can't be used as a type, only a type constraint.Allowing an extension to have both constraints and an inheritance clause shouldn't change this. It would still be a fully compile-time construct in the same way. I assume the only reason it hasn't been done is that it's an extra layer of complexity that someone needs to code into the compiler.

Just to clarify: I only wrote Array<T: Equatable> as a short/sloppy way of saying Array<T> where T (the element type, Element) conforms to Equatable.I think the syntax would probably be closer to one of the two alternatives I gave in the original post. The reasons for that can perhaps be seen by looking at this:// Here's is how it's currently possible (in Swift 2) to extend Array<T> where T (the element type, Element) conforms to Equatable. extension Array where T: Equatable { func countElementsEqualTo(value: Element) -> Int { // This method is only available for arrays where the element type (T / Element) conforms to Equatable. return self.reduce(0) { $0.1 == value ? $0.0 + 1 : $0.0 } } } let a1: [Int] = [2, 8, 2, 2, 7, 3, 2, 6] let a2: [Any] = [one, 2, 3.0, UInt8(4)] print(a1.countElementsEqualTo(2)) // 4 // print(a2.countElementsEqualTo(2)) // Error (as expected, since Any doesn't conform to Equatable)So, since the above is how the syntax is for extending Array<T>'s with constrai

Thanks for your reply ...last night I finally determined what was going on. Xcode 6.4 actually gave me a more verbose error message which helped.It turns out that I was using a struct as the object type in the dictionary. Even though you can implement the NSCoding protocol in a struct, you cannot inherient from NSObject. I changed the object type to a class, inherited NSObject, and updated the misc syntax changes in the protocol, and now everything works fine.Very odd .. it's things such as this that make using a new language interested 🙂Again, thanks for your reply.-gary