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 > <[email protected]> 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 <[email protected]> wrote: >> >>> On Feb 21, 2017, at 5:24 AM, Rod Brown <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
