[swift-corelibs-dev] Proposal: Make NSTask's standardInput/standardOutput/standardError properties type-safe
Tony Parker
anthony.parker at apple.com
Thu Dec 17 14:31:36 CST 2015
Hi Dan,
Thank you for your proposal. This is the right place to start discussion of it. If we want to do this then we would have to make changes in both Darwin and open source versions, to maintain source compatibility.
Out of curiosity, why propose an enum instead of an additional set of typed properties? Looking at the implementation of NSTask, it sure seems like we only expect either a file handle or pipe. I’m not sure if we would ever add another.
- Tony
> On Dec 17, 2015, at 11:34 AM, Dan Stenmark via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
>
> This is my first proposal to swift-corelibs, so I’m not sure how much flexibility we have in terms of deviating from the darwin’s original Foundation definitions. That said, it’s always seemed a little screwy to me that NSTask's standardInput/standardOutput/standardError properties sacrifice any semblance of compile-time type safety by accepting id/AnyObject (which, at run time, must be either NSPipe or NSFileHandle, else it blows up). If allowed, I’d like to take the opportunity to modernize this in the open source version of Foundation.
>
> public class NSTask : NSObject {
>
> ...
>
> public enum IOType {
>
> case FileHandle(NSFileHandle)
> case Pipe(NSPipe)
> }
>
> public var standardInput: NSTask.IOType?
> public var standardOutput: NSTask.IOType?
> public var standardError: NSTask.IOType?
>
> ...
>
>
> }
>
> Dan
>
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151217/99f7f8c3/attachment.html>
More information about the swift-corelibs-dev
mailing list