<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><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></body></html>