Re: Swift Interface vs Implementation
Re: Swift Interface vs Implementation
- Subject: Re: Swift Interface vs Implementation
- From: Quincey Morris <email@hidden>
- Date: Sat, 22 Nov 2014 02:24:27 +0000
On Nov 21, 2014, at 17:08 , Richard Charles <email@hidden> wrote:
>
> A header files forces you to separate the interface from the implementation. I always thought that was a good thing but apparently not.
It’s a good thing for the reasons why you think it’s a good thing, but it’s also a bad thing. The trouble is that header files basically cause you to replicate source code (and source keystrokes). The Swift tradeoff sacrifices direct API documentability for ease of coding. We developers have been whining about having to type everything twice for years now. Also, if you have interface and implementation files, you need twice as many tabs (or windows), so to speak. Removing half the files allows the UI to be more effective/flexible.
> But then again it appears that Apple may not be eating its own dog food because the interface appears to be separate from the implementation for the native swift stuff they provide.
IDK but I think the synthesized Swift “header” file is probably derived from the module file(s). They’re likely not files at all, or if they are they’re generated from compiled binary data.
> Also note that in the Xcode 6.1 native Swift “definition file” there are no access control levels. The file that is presented does not contain any of the keywords: public, internal, or private. So it appears Apple has separated the interface from the implementation for native Swift functions using some other technique.
Again, not necessarily. Apple released its headers using the original version of Swift that didn’t have the access controls. It may be that they just haven’t added them yet. Another possibility is that their real source files use access controls, but the keywords aren’t synthesized from modules and/or only the public parts are synthesized so that access control keywords aren’t judged necessary. Or, for the Cocoa frameworks, the need for interoperability with Obj-C might dictate that it’s not practical to use Swift syntax that doesn’t have a direct equivalent in Obj-C.
> But then again maybe I have spent too much time in C and Objective-C.
So maybe Swift is saving your soul, if only you’d let it? ;)
_______________________________________________
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