Swift and Inheritance
So what is the take-away when foundational types of the language that are classic examples of types that should be classes are implemented as structs? To me, it seems the API designers for Swift are already compensating for weaknesses in the language’s runtime and are trading supposed run-time performance over platform extensibility and that we, as developers of frameworks, should be doing the same.
SortedArray is perhaps a poor example, but I agree that there seems to be a code smell here. The more I learn about Swift, the more I see a, perhaps unavoidable, tension: Swift is (promised to be) faster, but Objective-C is more flexible. Swift doesn’t have much in the way of libraries, so it’s designed to work well with Objective-C’s, but there’s friction at this border.
What is the long-term plan? Keeping the frameworks all Objective-C would hold Swift back. But making pure Swift APIs would cut off access from Objective-C. Swift seems best-suited to lower level code where performance is more important than flexibility, i.e. the areas where Apple is now using C++ underneath an Objective-C API. But Apple is clearly pushing for its use on the other side of Objective-C, calling in.
4 Comments RSS · Twitter
It will be interesting to see which framework teams in Apple adopt Swift first. From a total outsider's perspective, it seems like the framework teams are free to choose whichever language they want, even if another language might be a more natural fit. Given how few people inside of Apple even knew of Swift, I wouldn't be surprised if some frameworks teams had no idea it was coming, and thus didn't provide input on what they need in a language.
Swift has a lot going for it to make it attractive to the frameworks teams, but some of them seem pretty obstinate, and I'm not sure if they;d give up their favorite languages without some kind of top-down companywide push. But from an engineering perspective, that could seem like management trying to force a square peg into a round hole, which I suspect would generate significant pushback.
I suspect that the frameworks teams that adopt Swift first are those for whom Swift's features are most attractive, and that should give us a good indication if Swift is better suited to low-level work, to high-level work, or to both.
Also possible is that Swift will fail. That is, that people will stick with a mix of Objective-C, C, and C++, and not adopt Swift.
