“SwiftData inheritance relationship”

Thanks Kem. I was at that talk. I will give it a watch again. We were looking for a lot more, and lower level info. The time of the boxes and their relationships on the timeline is useful, but without more info about WHY some things are happening (e.g. some of the unexplained whitespace 'time') it doesn't give a lot that is actionable. But it did just help me squash some unintentional buffer reloads. 🙂Just made me realize I wish we could give encoders proper names.>>Shift+mousewheel will scroll any scrollview horizontally in OS X.Got it. Hope that gets changed. Different keys for zooming and scrolling is super awkward. Dragging time should be a drag - like pretty much any DCC application.

You're probably getting this error because a class which PFObject inherits from already conforms to Equatable.Since protocol conformance is inherited, you can't declare that protocol conformance again in a subclass, but you can override non-final methods required by the protocol or provide more specifically typed versions of operators.Generally, the most specific version available of overloaded functions will be used by the compiler (based on how the objects are typed in the calling code), so your implementation of == would be used for two instances typed as PFObject, rather that the parent class's version.

The problem here is that NSUserDefaults is ultimately backed by a file in your app’s container and your app’s container is subject to data protection. If you do nothing special then, on iOS 7 and later, your container uses NSFileProtectionCompleteUntilFirstUserAuthentication, a value that’s inherited by the NSUserDefaults backing store, and so you can’t access it prior to first unlock. IMO the best way around this is to avoid NSUserDefaults for stuff that you rely on in code paths that can execute in the background. Instead store those settings in your own preferences file, one whose data protection you can explicitly manage (in this case that means ‘set to NSFileProtectionNone’). There are two problems with NSUserDefaults in a data protection context:Its a fully abstract API: the presence and location of its backing store is not considered part of that API, so you can’t explicitly manage its data protection.Note On recent versions of OS X NSUserDefaults is managed by a daemon and folks who try to ma

This is what I tried first:extension Array: StringInitializable where Element: StringInitializable { //error: extension of type 'Array' with constraints cannot have an inheritance clause //... }...Second try:extension Array : StringInitializable { init?(_ s : String) { let whiteSpaceRemoved = String(s.characters.filter { ! tnr.characters.contains($0) }) let bracketsRemoved = String(whiteSpaceRemoved.characters.dropFirst().dropLast()) let arrayOfStrings = bracketsRemoved.characters.split(,).map { String($0) } print(arrayOfStrings) // Prints eg [1, 2, 3] let arrayOfOptionals: [Element?] = arrayOfStrings.map { if let myElementType = Element.self as? StringInitializable.Type { return myElementType.init($0) as! Element? } else { return nil } } if arrayOfOptionals.contains({$0 == nil}) { return nil } self = arrayOfOptionals.map{$0!} } }Looks like working:let ok = [Int]([1, 2, 3]) print(ok) //->Optional([1, 2, 3]) let meh = [Int]([1, 2.0, 3]) print(meh) //->nil

CharlesS: Am I correctly interpreting this comment to mean that Apple is planning on having non-fragile base classes by the time the ABI is stabilized?Given Swift 2's failure to require methods always reference `self` when accessing members, I'd say Good luck with that!To illustrate, consider the following example:Their library:// v 1.0 public class TheirBaseClass { public func doThis() {...} }Your program:class MyClass: TheirBaseClass { func doMyThing() { doThat() } } func doThat() {...}And this is all well and good... until they add a shiny new instance method whose name is coincidentally the same as your existing global function:// v 1.1 -- added a new method named `doThat` public class TheirBaseClass { public func doThis() {...} public func doThat() {...} }Next time you hit compile, all of a sudden your `doThat()` is being dispatched somewhere else entirely, even though your code hasn't changed at all. (Ditto for global vs inherited variables and constants too.)I can only assume someone must've m

What I fail to understand is why you want to abstract it out of the class the first place. It's just a single method.And as a second point: protocols are intended, as in Obj-C, to define behaviour like compareable. It is not a poor mans multiple inheritance as interfaces in java or c++.

I asked specifically about 'coding style' because there is something about my modelling style that causes me to hit these issues _every_ time.If I don't expose `var Relationship : Set<Relationship>` and instead add methods like `addFriend`, `mapFriends`, `mapRivals`, etc (all the different facets of a Relationship - or addRelationship:as:) then the problem is avoided - Relationship becomes an implementation detail of Person. That is workable; maybe I learn something about modeling from that.Regarding the 'infinite recursion', is there not something like a `where` clause on a `typealias`?protocol Person : Hashable { var fullname : String { get set } typealias R : Relationship where R.P == Self var relationships : Set<R> { get } }

I would recommend that you stick to NSInteger / NSUinteger for integer values and CGFloat for floating point values (float and double). These are the default types used in the Apple libraries. They will also use the largest size (32 or 64 bit for integers) supported by the target CPU. Integer values like short, int, long, long long etc are simply defined as having a size relationship like this: short ≤ int ≤ long ≤ long long with no guarantee for the actual bit size. Type sizes can vary between compilers / OS platform. There are also a number of fixed size types (int8_t, int16_t, ... uint8_t, uint16_t, ...) if you need to ensure a specific size.

It's a bug. Your subclass initializer wouldn't really be an override of the parent initializer; they just happen to have the same name. Since initializers aren't automatically inherited in Swift, this would be perfectly safe. Please file a bug report!

Not exactly. You can't just set a timer and then start scanning when it expires. You need to consider that the user will press the home button or lock the phone.In those cases, your timer will stop working.What you need to do is keep scanning, and when you get the discovery callbacks, check the time to see if enough time has passed - if not, do nothing and keep checking the time. If you are actively scanning, even if your app is backgrounded, the system will activate your app when the BLE peripheral is advertising.You should also look at CoreBluetooth state preservation/restoration in case your app gets terminated by the system while in the background. More info here: https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW5I can't help you with your architecture decisions, but if it would help; another way of looking at the ce