[swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

[Rod Brown]

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.

Rod

> On 22 Feb 2017, at 7:43 am, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
> 
> My concern regarding a new class in the overlay is interoperability.
> 
> 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.
> 
> 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.
> 
> 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?
> 
>> On 22 Feb 2017, at 1:40 am, Charles Srstka <cocoadev at charlessoft.com> wrote:
>> 
>>> On Feb 21, 2017, at 5:24 AM, Rod Brown <rodney.brown6 at icloud.com> wrote:
>>> 
>>> 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.
>>> 
>>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> Thanks,
>> Charles
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170222/9098dcc8/attachment.html>