Daniel Duan's Articles About Foundation

Daniel Duan's Articles About Foundation https://duan.ca/tag/foundation/ A Tale of Two Dates Recently, I discovered a curious thing about <code>Date</code>s in two large projects I work on. Simply put, both projects receives, from various HTTP endpoints, the same object component: a timestamp, and a duration. Combining these two pieces, both projects derives two <code>Foundation.Date</code>s to represent a time range. So far, so good. However, project <code>A</code> uses <code>Fonudation.DateInterval</code> to represent this concept, while project <code>B</code> uses <code>Range<Date></code>. But why? Why represent the same component differently? What a gigantic waste of brain power for everyone on both projects! So I set out to unify this thing. Wherever a <code>Range</code> literal is used, I swap in <code>DateInterval.init(start:end:)</code>; <code>Range.lowerBound</code> becomes <code>DateInterval.start</code>; <code>Range.upperBound</code> becomes <code>DateInterval.end</code>, etc. It didn't take long to complete the conversion to <code>DateInterval</code> in project <code>B</code>, now it builds and runs! Oh, wait, why are some tests failing in project <code>B</code>? Shouldn't this just be an mechanical change? I spent time investigating. The failing tests are for some very specific business logic that I'm not familiar with. So things took a while to become clear. What felt like a long time later, I realized my mistake. (I'm sorry if this has been obvious to you. You are a better Swift programmer!) Somewhere in project <code>B</code> is the following: <pre><code class="language-swift">struct Item { let range: Range<Date> } struct Container { let items: [Item] } func containerFactory(range: Range<Date>, items: [Item]) -> Container { /// pretend there's more code here return Conatiner(items: items.filter { $0.range.contains(range.lowerBound) }) } </code></pre> And of course, after my "refactor", it became <pre><code class="language-swift">struct Item { let range: DateInterval } struct Container { let items: [Item] } func containerFactory(range: DateInterval, items: [Item]) -> Container { /// pretend there's more code here return Conatiner(items: items.filter { $0.range.contains(range.start) }) } </code></pre> Tests for <code>containerFactory</code> failed. And here's why: <code>DateInterval.contains</code> is inclusive for its upper bound (<code>.end</code>), whereas <code>Range.contains</code> isn't! You can see it plainly by running the following <pre><code class="language-swift">import Foundation let sooner = Date(timeIntervalSince1970: 0) let later = sooner.addingTimeInterval(1000) DateInterval(start: sooner, end: later).contains(later) // true (sooner..<later).contains(later) // false </code></pre> So here's what stumped me: <ol> <li> The 2 projects chose to interpret the same component differently, which I didn't not expect. </li> <li> I didn't know how <code>Foundation.DateInterval</code> works. </li> </ol> Well, today I learned. Sat, 25 Aug 2018 17:11:43 -0700 https://duan.ca/2018/08/25/a-tale-of-two-dates/ https://duan.ca/2018/08/25/a-tale-of-two-dates/ Supporting Foundation.Data Without Depending On It While implementing some file I/O APIs in <a href="https://github.com/dduan/Pathos">Pathos</a>, I decided reading/writing file content as <code>Foundation.Data</code> is kind of important (can you blame me?). But Pathos, by accident, does not depend on Swift <code>Foundation</code>. Now what? After browsing the <a href="https://developer.apple.com/documentation/foundation/data">documentation</a>, a pretty good solution emerged: <code>Data</code> is a sequence of bytes! Lets say we hand our users some bytes, they can easily construct a <code>Data</code> from it: <pre><code class="language-swift">let content: [UInt8] = try readBytes(fromPath "/tmp/test") Data(bytes: content) </code></pre> Okay, so this built-in initializer makes <code>[UInt8]</code> an acceptable substitute for returning <code>Data</code>. What can we do about about <code>Data</code> as input? Well, turns out, <code>Data</code> is a <code>Collection</code> of <code>UInt8</code>s! So we can accept <code>Data</code> indirectly like so: <pre><code class="language-swift">func write<Bytes>(_ bytes: Bytes) where Bytes: Collection, Bytes.Element == UInt8 { // blah } </code></pre> User can pass in a <code>Data</code> as argument and it just works™. The only disadvantage of supporting <code>Data</code> in these ways is that it requires your user to discover it either via your excellent documentation, or through their super good knowledge of <code>Foundation</code>. Update: this could also <a href="https://mastodon.social/@helge/100573358160444340">be</a> <a href="https://twitter.com/daniel_dunbar/status/1030938273047179264">slower</a> than using Data directly. Luckily I'm only doing file I/O here. But this is pretty nice, regardless. Sat, 18 Aug 2018 11:00:41 -0700 https://duan.ca/2018/08/18/supporting-data-without-depending-on-it/ https://duan.ca/2018/08/18/supporting-data-without-depending-on-it/ Contributing To Open-Source Swift I discover, report, fix and merge a bug in the open-source Foundation project. And why, yes, on YouTube. <div class="video-container"> <iframe src="https://www.youtube.com/embed/rwuj80W8TtI" frameborder="0" gesture="media" allow="encrypted-media" allowfullscreen></iframe> </div> <ul> <li>Pull request: <a href="https://github.com/apple/swift-corelibs-foundation/pull/1376">https://github.com/apple/swift-corelibs-foundation/pull/1376</a></li> <li>SR-6647: <a href="https://bugs.swift.org/browse/SR-6647">https://bugs.swift.org/browse/SR-6647</a></li> </ul> Sat, 23 Dec 2017 13:21:10 -0800 https://duan.ca/2017/12/23/contributing-to-open-source-foundation/ https://duan.ca/2017/12/23/contributing-to-open-source-foundation/