I realize this ship has probably sailed a long while ago. I really like the way the Foundation library is shaping up. With the changes in Swift3, I’ve been moving any of my Array<Uint8> cases to using Data. A handful of handy extensions to Data have made working with it nice. It’s much easier to figure out how to extend Data than Array<UInt8>. And of course, the UIKit/Cocoa libraries love Data things.
That said, one minor nit I’ve noticed, especially with the inclusion of Date and the dropping of the NS prefixes, is that when I’m scanning code, Date and Data look a lot a like. Where Swift tries so hard to be expressive, this ends up being a dissapointment. My particular app uses quite a bit of both.
Of late, I’ve added a
typealias Bytes = Data
and begun replacing Data references with Bytes.
It’s too early to tell if its a good replacement or not. I recognize this is a minor issue, rooted in the history of NSData and who knows what else. But I thought I’d shared the feedback anyway.
If you think Date and Data look similar at a glance, wouldn’t NSDate and NSData? Or are you comparing this against your old Array<UInt8> type?
···
On Aug 3, 2016, at 6:33 PM, Travis Griggs via swift-users <swift-users@swift.org> wrote:
I realize this ship has probably sailed a long while ago. I really like the way the Foundation library is shaping up. With the changes in Swift3, I’ve been moving any of my Array<Uint8> cases to using Data. A handful of handy extensions to Data have made working with it nice. It’s much easier to figure out how to extend Data than Array<UInt8>. And of course, the UIKit/Cocoa libraries love Data things.
That said, one minor nit I’ve noticed, especially with the inclusion of Date and the dropping of the NS prefixes, is that when I’m scanning code, Date and Data look a lot a like. Where Swift tries so hard to be expressive, this ends up being a dissapointment. My particular app uses quite a bit of both.
Of late, I’ve added a
typealias Bytes = Data
and begun replacing Data references with Bytes.
It’s too early to tell if its a good replacement or not. I recognize this is a minor issue, rooted in the history of NSData and who knows what else. But I thought I’d shared the feedback anyway.
_______________________________________________
swift-users mailing list
swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Fair question. I did think of that. I did actually port this code from Objective C. For whatever reason, it wasn’t as noticeable (to me) there. ObjC doesn’t lend itself to as “tight” of code, it’s got extra verbosity everywhere, so maybe it was less noticeable in that case. I honestly don’t know.
I realized right after I wrote this, that I could also
typealias Timestamp = Date
And reap similar benefits. The fact that some have coined data as "The World's Worst Variable Name” makes me tend to shy away from it already I guess.
···
On Aug 3, 2016, at 3:36 PM, Jon Shier <jon@jonshier.com> wrote:
If you think Date and Data look similar at a glance, wouldn’t NSDate and NSData? Or are you comparing this against your old Array<UInt8> type?
Yeah, of the two NSDate is the one that’s misnamed IMO. The name gives the impression that the value is somehow related to the calendar, which it isn’t. NSTimestamp, NSDateTime, NSAbsoluteTime, and so on would all be better.
Of course, fixing this would be… challenging.
Share and Enjoy
···
On 3 Aug 2016, at 23:43, Travis Griggs via swift-users <swift-users@swift.org> wrote:
I realized right after I wrote this, that I could also