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 12:53:20 -0500
On Mar 11, 2015, at 12:03 PM, Quincey Morris <email@hidden> wrote:
>
> On Mar 11, 2015, at 02:36 , Charles Srstka <email@hidden <mailto:email@hidden>> wrote:
>>
>> Rewriting all the frameworks in another language
>
> No, no, no, that’s not the suggestion. The suggestion is to rewrite the *SDKs* in Swift. Public headers only. Almost all of the rewrite would be an automatic conversion that exists already.
>
> Swift sorta has the concept of headers already, as you see when you command-click a library symbol, and it has both directions of declaration bridging (to and from Obj-C .h files), in at least a limited way. So instead of annotating Obj-C and bridging to Swift, bridge to Swift one time, then fix and make that the official SDK source, then bridge back to Obj-C again.
>
> It’s a bit of a fantasy, because this would in practice be inconvenient for writers of frameworks, but I suppose you could further fantasize that Obj-C would #import Swift “header” files directly.
Well, what would happen when the Swift headers inevitably got out of sync with the “real” headers, as commonly happens with the documentation? Also, what about APIs that are only available in C/Obj-C and not exposed to Swift?
It would also be much more work. With the annotations idea, the only modifications that would need to be made would be to APIs that returned some kind of collection type, not the entire headers.
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