Hi Tony, thanks for the response! In regards to why an enum w/ associated values:
- It avoids creating additional storage. (Admittedly, a very small amount, but the point still stands.) - It deterministically defines that it’s either one or the other, and guards against someone trying to be clever and setting both the Pipe and Handle properties. Even if we do have a safeguard for that (like “setting the Pipe property nils out the File Handle property” and vice-versa), making it a type-safe enum improves API clarity. I’m generally not a fan of implicit API behaviors that require reading the fine print, and while they are necessary sometimes, I’d much prefer the class’s declaration makes it clear from the get-go. - Furthermore on the previous point, it helps encourage safer client usage patterns for callers getting pre-launched NSTask objects from opaque factory methods. (I don’t see this pattern out in the wild very much, but I don’t want to rule it out, especially if Swift starts taking off on the server-side). Dan > On Dec 17, 2015, at 12:31 PM, Tony Parker <anthony.par...@apple.com> wrote: > > 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@swift.org <mailto:swift-corelibs-dev@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@swift.org <mailto:swift-corelibs-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
