<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Ah sorry! To be honest, I didn't see the part about your interoperability with NSProgress trees!</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">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?</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">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.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Rod</div><div><br>On 22 Feb 2017, at 7:43 am, Rod Brown via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><span></span></div><div><div><span></span></div><div><div>My concern regarding a new class in the overlay is interoperability.</div><div><br></div><div>With a lot of things in the Swift Overlay, identity isn't relevant. For example, we turn a lot of Objective-C classes into structs because their identity is not relevant, and they should be copied anyway, so it makes sense to let the Swift world be different.</div><div><br></div><div>Progress however has innate identity for tracking purposes. Separate Progresses for Swift and Obj-C causes problems. If I want to pass my progress to an Obj-C API, I can't hand it my Swift progress, I must hand it an Obj-C one.</div><div><br></div><div>I can't foresee how a new Progress will integrate cleanly with existing NSProgress API. Is it worthwhile creating a separate class that is incompatible with Obj-C Foundation?</div><div><br>On 22 Feb 2017, at 1:40 am, Charles Srstka <<a href="mailto:cocoadev@charlessoft.com">cocoadev@charlessoft.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><blockquote type="cite" class="">On Feb 21, 2017, at 5:24 AM, Rod Brown <<a href="mailto:rodney.brown6@icloud.com" class="">rodney.brown6@icloud.com</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I applaud the idea. I too find the (NS)Progress API to be very low quality. It seems a vestige of an earlier time when Cocoa was young and APIs that seem like they should be simple, just... aren't. I would love to see a much better API developed.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I'm curious how this idea of developing something from the ground up works with Apple's preferred idea of using Swift to bring Foundation forward.</div></div></blockquote></div><br class=""><div class="">There are several ground-up replacements in the Swift overlay already, if you look at the various value types that have been introduced to replace various NS classes (granted, some of them call through to the underlying Foundation API for their implementation, but others don’t). As long as we eventually end up supporting NSProgress’s interface, something like this should be possible to drop in as long as we do it before the ABI stability lockdown.</div><div class=""><br class=""></div><div class="">In any event, I BSD-licensed the code, so it’s free to use whether or not Apple ends up using it, so feel free to give it a try (for performance testing, be sure to compile in Release mode, as it does much better with the optimizations on). If you find any bugs or problems, please let me know.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Charles</div><div class=""><br class=""></div></div></blockquote></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>