It's an interesting implementation, from my cursory look. Inspired by the bridging wrappers that the rest of the Swift Overlay uses, and with a massive performance win in Swift-only uses. Awesome!
It still holds the fundamental oddities of NSProgress that I find weird. Like "current progress" always strikes me as very odd concept. I'd be interested to see what Tony Parker and the Core Team think! On 22 Feb 2017, at 8:22 am, Charles Srstka <cocoa...@charlessoft.com> wrote: >> On Feb 21, 2017, at 2:52 PM, Rod Brown <rodney.bro...@icloud.com> wrote: >> >> Ah sorry! To be honest, I didn't see the part about your interoperability >> with NSProgress trees! >> >> That said, it does seem to be a hacky solution. A better solution would be a >> backing NSProgress that is linked and lazily created when casts occur, >> perhaps? This would map far cleaner to current bridging techniques in the >> Swift Overlay? >> >> Sorry, I haven't looked at how your internal implementation is done. I'm >> just going off the description in your email. I'm curious to get involved in >> creating a better progress API if we can find a way that is superior and >> still cleanly interoperates. > > Agreed that it’s hacky, which is why I tried to do my best to separate the > Objective-C compatibility crud from the rest of the code, so it can be easily > yanked and replaced with something better if we think of one. > > With that said, the way I’m currently doing it is inspired by the way the > Data<->NSData bridging works. My class, CSProgress, has a “backing” property. > This property stores an enum with two cases, one for Swift, and one for > Objective-C. The Swift backing contains the basic implementation, and the > Objective-C one wraps an NSProgress, forwarding all changes to it and > registering for KVO notifications on it for the purpose of keeping its own > clients notified. Each case contains an associated type that handles all the > primitives. There’s also a private NSProgress subclass (unimaginatively named > “BridgedNSProgress”) that wraps a CSProgress, and forwards NSProgress changes > to it. > > What you get if you: > > - create a CSProgress from scratch, or from another CSProgress: A CSProgress, > with the Swift backing. > > - bridge an NSProgress to a CSProgress: If the NSProgress was a > BridgedNSProgress, you get the CSProgress it was wrapping. Otherwise, you get > a CSProgress with the Objective-C backing. > > - bridge a CSProgress to an NSProgress: If the CSProgress uses the > Objective-C backing, you get the NSProgress it was wrapping. Otherwise, you > get a BridgedNSProgress wrapping the CSProgress. > > If no bridging occurs and you’re using CSProgress all the way down, no > NSProgress objects get involved. > > Charles > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
