“SwiftData inheritance relationship”

Not sure if this will help or not, but, I have experienced something similar with Ordered relationships within Core Data. Here is what I ended up doing.- (void)addReportQueriesObject:(ReportQuery *)value { NSMutableOrderedSet* tempSet = [NSMutableOrderedSet orderedSetWithOrderedSet:self.reportQueries]; [tempSet addObject:value]; self.reportQueries = tempSet; }basically I have to initialize a new ordered set, add my new value to that newly allocated ordered set, THEN save that into my ManagedObject. Hope this helps!

Actions are not inherited from the parent, really, but the effects of property changes are. So you have 2 choices:1. When you add an action to the parent, add an inverse of the action to the children. That is, if you move the parent 10 to the left, move the children 10 to the right.2. Rethink your design. If the children don't reflect changes to parent properties, they probably shouldn't be children.If you have other reasons for associating these children with this parent, then I suggest you create a plain SKNode, and make the children subnodes of that. Then create another plain SKNode, and make the parent and first SKNode children of that. With that structure, you can chose which parts of the hierarchy you want actions to affect.

Right now I have:planetNode that has action to follow a path (oval) and another action to rotate by angle all the time. This node is inherited from SKSpriteNode, it also has added other things: - a mouse over effect (action for blinking node when mouse is over planet)- a mouse click (an action that should stop blinking and instead show child that is actually a square that is drawn around planet, but it should move with planet all the time when it is selected).I have disengaged planet shadow node (this is normal SKSpriteNode now) and it is just following planet on same path action, but it has own rotating action. All fine and good, but now selecting and hovering isn't working, as planet is under shadow node. Ok I understand, that I'm trying to have events on object that doesn't have them, but making shadow clickable and hoverable object type is defeating a purpose of selecting a planet as I then don't know which planet is actually under that shadow. Shadow can be same on multiple planets. Only solutio

I've found some others, but couldn't find a sectioned one.Here's what I'm thinking of trying to do, perhaps someone can let me know if this is a bad idea.1) Create an SectionArrayController subclass of NSArrayController. Set its entity to the entity for the object that represents the 'sections'.2). KVO arrangedArranges within my view controller, and reload my user interface when changes are detected.The problem with this is, SectionArrayController does not report child object changes, when a object is added to the section. So if you add a object to a given section (a to many relationship), you won't get the change and the user interface will be out of sync.So I'm thinking of adding another array controller as a property to the SectionArrayController subclass..and have the section array controller kvo the array controller for the items in the section...and programmatically calling a rearrangeObjects to force a refresh.Kind of ugly set up, but I guess it's better than reinventing the wheel and writing

Common approaches in the past... is for individual apps to request notifications from the Battery Service and either/both: a) display battery status internally and/or b) use iOS notification pop-up when power is low. This approach requires an opt-in from the user (intentionally running the app in the background and either checking it regularly or allowing it to do iOS notifications).See:http://stackoverflow.com/questions/17...But I think using NC risks confusing the user by displaying multiple battery level indicator, where they've been trained by Apple to expect a 1:1 relationship in that example.

>I've not really found a way of using them to structure large/complex types that feels just right.Be careful of mis-calibrating expectations... Swift is still young, still being fleshed out, still finding itself - it won't turn the corner where the new wears off for some time yet, so if you're expecting comfort similar to other, time-worn langs, it might be too early to hope for that kind of relationship just yet.In the mean time, file bugs and be patient.

Alas, your question does not make any sense given the realities of binary floating point. First up, some overall comments:Swift uses Double as its standard floating point type. double_t is a compatibility thing inherited from C code. It only works in this context because you’re importing Foundation.Swift’s Double type is defined to be an IEEE 754 ‘double’ (binary64), which means it uses binary floating point.The fact that Double uses binary floating point means that questions about decimal places don’t make a lot of sense in Swift. For example, consider this snippet: let a: Double = 0.2 let b: Double = 0.1 let c: Double = 0.3 let sum = a + b print(sum == c) // prints falseIf you look at the binary representation of these values it’s easy to see why:print(String(unsafeBitCast(a, UInt64.self), radix: 16)) // prints 3fc9_9999_9999_999a print(String(unsafeBitCast(b, UInt64.self), radix: 16)) // prints 3fb9_9999_9999_999a print(String(unsafeBitCast(c, UInt64.self), radix: 16)) // prints 3fd3_3333_3333_333

A Swift function signature includes its names, input parameters and its return type. So, if you wrote this:let f = E().arbitraryFactory()what would f's type be? The compiler would complain that f's type is ambiguous; it's not clear which of the two functions should be called, whether a B or an E should be returned. You'd need to make it explicit:let f : B = E().arbitraryFactory()The reason one requires an override and the other does not: returning an E doesn't conform to the 'super' function signature, but returning a B does, because a B is an A. What matters with the inherited function is that, when called, an A is returned; the overridden signature is allowed to be more specific about its return type.With the identity function the same can't be said; the 'overridden' signature type isn't general enough with its input arguments - E().identify(A()) would call D's function, not E's, because E's isn't general enough.

>> But this means that the generic Number isn't there and sometimes this is a useful simplification. You can still use NSNumber explicitly in Swift, if you want to.>> So given that the Swift types are value types, and those can be inherited,They can't. Double and Int are structs. There is no inheritance for Swift structs.>> is there any reason Double and Int couldn't be decendants of Number? They don't really have the same behavior, beyond the basics.>> Or is such a thing possible now?You could define your own protocol that includes behavior common to Double and Int, and extend those classes to conform to it. But my guess is that it's going to get pretty ugly, because you'll have trouble with things like literals, unless you make your protocol very complicated.