Re: Swift Interface vs Implementation
Re: Swift Interface vs Implementation
- Subject: Re: Swift Interface vs Implementation
- From: Daniel Blakemore <email@hidden>
- Date: Fri, 21 Nov 2014 22:09:50 -0700
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 <
email@hidden> wrote:
> 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
>
_______________________________________________
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