Re: NSRunningApplication executableURL issue in Swift
Re: NSRunningApplication executableURL issue in Swift
- Subject: Re: NSRunningApplication executableURL issue in Swift
- From: Charles Srstka <email@hidden>
- Date: Wed, 11 Mar 2015 04:36:47 -0500
On Mar 11, 2015, at 2:51 AM, Quincey Morris <email@hidden> wrote:
>
> On Mar 11, 2015, at 00:25 , Charles Srstka <email@hidden <mailto:email@hidden>> wrote:
>>
>> You know, this sounds like a good candidate for a collection contents annotation, similar to the nullability annotations that were recently added to Xcode. If there was a way to notate in an Objective-C header that this method returns an NSArray of NSStrings instead of just an NSArray of anything, it would make using Objective-C objects from Swift a lot easier.
>
> Running with this idea to an extreme, I could see value in “writing” the OS X 10.11/iOS 9 SDKs in Swift, and porting them in the opposite direction to make the Obj-C header files. If you’re going annotate things, it would be more effective to start from the more expressive language.
There are some problems with that, though:
1. In Apple’s case, there’s a *huge* existing codebase. Rewriting all the frameworks in another language would take *far* more effort than annotating the collection objects that show up in header files. It would also force Apple to drop 32-bit application support, since Swift can only be compiled to 64-bit binaries, and Apple may not be ready to do that yet.
2. In the general case, Swift doesn’t work very well for frameworks, since AFAIK the ABI still hasn’t stabilized yet. So if you tried to link against a framework that was built with a different version of Swift than what you’re compiling your app with, it wouldn’t work. So, Swift can be used for frameworks you’re compiling alongside your application and embedding within it, but not for any framework that needs to meet third-party code. This will, of course, eventually change, but for now it’s not quite ready for that.
> Actually, I’m not at all sure there isn’t a place for user-written “header” files in Swift generally. It’s duplicative, I know, but it’s much better documentation (especially of public APIs) than the actual source files.
Oh, no question there. Unfortunately, header files, despite their major advantages to documentation, seem to be considered “antiquated" on the same level as MRC these days by the kiddos who come from languages like Java, and that way of thinking seems to have influenced the compiler team. I shudder to think of how hard the frameworks will be to use if they ever get ported and we lose the headers — just look at how many functions and methods in the SDK that have been around for years are still not documented anywhere other than the header files.
Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden