Since this seems like a two cents-style discussion, I figured I'd add mine.
"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." I've personally never whined about any of this. I really like have a place to put all my documentation that is cleanly separated from where the actual work gets done. In larger files, the large headerdoc comments would destroy any sense of position in the implementation file with unnecessary bloat. If I had to scroll past all the giant comments with discussions about usability and edge cases, I'd get frustrated every time I had to work on that file. Plus, separating the two keeps the implementation details out of the hair of people who are reading a header to learn how to use your library/api/interface. "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." <aside>Maybe they are and it's giving them as much trouble as it is some of us which could explain recent lapses in quality control for both OSs.</aside> Some examination and explanation of the documentation style for Swift can be found on the website of the wonderful Mattt Thompson ( http://nshipster.com/swift-documentation/) written back in July. So it appears that at least the quicklook documentation is doable with comments in the .swift file alongside the code. I think Swift will be slow uptake for large projects (although notably, AFNetworking was re-written [updated?] in Swift as AlamoFire, so someone [Mattt] is onboard) because it does so many things differently than what we are used to and deadlines don't lend themselves to learning new syntax. Plus, there are still going to be growing pains (try typing the characters "@auto" in a swift file to see what I mean) as swift support and the swift compiler get more mileage and more improvements. A half-client/half-friend of my company who's been writing code for a long long time, commented to me that the way swift and it's compilers are developing remind him of the way C was when it was new and FORTRAN was king. I don't think that Swift is the new C, but it does have some issues that need to be worked out/around or at least explained before I move over. -- Daniel Blakemore Pixio Software On Fri, Nov 21, 2014 at 7:24 PM, Quincey Morris < quinceymor...@rivergatesoftware.com> wrote: > 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/dblakemore%40pixio.com > > This email sent to dblakem...@pixio.com > _______________________________________________ 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
