> On Dec 9, 2015, at 6:40 AM, Perry E. Metzger via swift-users
> <[email protected]> wrote:
>
> This will also require a bit of design to look "Swifty”.
Yes, amen. The thought of a Swift bridge to the standard C library gives me
queasy thoughts of PHP, whose core APIs are a horrible pidgin translation of C.
An I/O library should begin with an abstract stream API, which can then be
given a concrete file-descriptor-based implementation that can be used for
files, sockets, etc. (Although the fact that it’s based on file descriptors
should be hidden.)
IMHO one of the biggest design problems of Foundation is that it has very weak
support for streams. NSStream is very difficult to subclass, and most I/O
doesn’t even use it, so there are historical remnants like NSFileHandle and
high-level alternatives like -[NSData initWithContentsOfFile:] that everyone
ends up using.
> A lower layer is also needed -- simple Swifty wrappers for the Unix
> system calls so that Swift implementations can get at them without
> having to use unsafe constructs. open(2), read(2), write(2), lseek(2)
> and close(2) would provide about 75% of what one needs for the higher
> layer stuff (and everything one would want for stdio) with quite
> minimal hacking.
I agree, but I foresee problems in the future when Swift is ported to Windows.
:/
—Jens
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
