On Nov 21, 2014, at 17:08 , Richard Charles <rcharles...@gmail.com> 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 (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

Reply via email to