On Mar 11, 2015, at 3:55 PM, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote: > > On Mar 11, 2015, at 10:53 , Charles Srstka <cocoa...@charlessoft.com > <mailto:cocoa...@charlessoft.com>> wrote: >> >> It would also be much more work. > > Actually, I don’t think so, once you follow through the argument… > > Even today, the ability to cross-translate between Swift an Obj-C exists > (within the Swift compiler, though used only in particular bridging > contexts). Within certain limits of interoperability, this means that the > “real” SDK headers could be in Swift language or Obj-C language, with > on-the-fly translation in one compiler or the other. (Because, by definition, > what’s in the SDK is limited to what’s interoperable.) Conceptually at least, > that’s unrelated to what language** the frameworks are implemented in.
Yes, but every time you make any change to the frameworks thereafter, you have to make sure to keep the two in sync. Better to avoid the duplication of data. > Thus, my argument goes, if you desire to go through the process of > “annotating” the SDK for something like array member types, you could either > extend Obj-C with annotation syntax, or you could simply start with and use > existing Swift syntax. > > Either way, the bulk of the work is auditing. That is, it’d be necessary to > re-audit the SDK headers (just like is being done now, or perhaps has been > done recently, I’m not sure how far along this is). The big task is the > necessary work of *finding* what needs to be changed. The actual changes are > relatively small in number. While that’s true, it’s a much easier task than auditing for nullability. With the latter, you have to pore through the code to see if there’s any possibility, even a small one, that an API could return nil. If the API calls other APIs to calculate its result, then you have to inspect those too. The contents of NSArrays and such, on the other hand, are usually pretty obvious, and can usually be inferred by a human simply by looking at the header (indeed, if this weren’t the case, it wouldn’t be a very good API to begin with), which is a much less involved process. > Of course, such a task isn’t literally possible today, though we seem to be > close to feasibility. Off the top of my head, I’d guess the biggest problem > would be ivars defined in public SDK headers. I suspect that the 32-bit OS X > ABI would have to be abandoned, since I think think that’s the only reason > those ivars are still there. > > > ** Frameworks that are untranslatably C-based would not be interoperable with > Swift anyway, so their headers would have to stay as they are. I was thinking more about headers that have some C-based functions that are translatable and some that aren’t. Charles _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
