[swift-corelibs-dev] Proposal: Make NSTask's standardInput/standardOutput/standardError properties type-safe

[Dan Stenmark]

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.parker at 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 at swift.org <mailto: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 <mailto: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/467cf789/attachment.html>