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. -Rod > On 18 Feb 2017, at 6:48 am, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Feb 17, 2017, at 1:42 PM, Charles Srstka via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> - Much better performance. In my testing, updating the >> completedUnitProperty, with something observing it, takes 1.04 seconds on my >> 2013 Retinabook, compared with NSProgress’s 52.91 seconds (58.53 seconds if >> an autorelease pool is used). This frees back-end code from the >> responsibility of being adulterated with what is effectively UI code in >> order to determine when the progress object should be updated. > > This should have said “updating the completedUnitProperty one million times, > with something observing it.” I eagerly await the implementation of our new > forum, hopefully with an edit feature, with bated breath. > > Charles > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
