> On 13 Jun 2015, at 1:31 pm, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > One of the biggest old-school reason is source duplication. You have to write > everything “twice”, once in @interface, once in @implementation. This has > been mitigated somewhat over the years, but Obj-C is literally twice the > number of files as Swift, and (in my experience so far) twice the number of > source lines to do the same thing. >
To me this is actually a good thing that I’ll be sorry to see go away in Swift. With a separate header that only contains the public stuff, I can see at a glance what a class does without being overwhelmed by its implementation details. It’s like the table of contents for a text book, or a road map. If I have everything in the one file, that nice roadmap has gone, and I have to sift through lots of extraneous detail to get a sense of what a class does. It’s also untrue that you have to write *everything* twice - you have to write the method definitions twice, which is a minor bit of work. In practice really not much, and it’s good discipline. I assume Swift has a way to separate the publicly exposed interface from the private, but it’s still very handy to have it all gathered in one place. I won’t mind too much if there are tools that simply extract the public stuff and present it (in the browser view say), but then it’s making the language somewhat dependant on a graphical UI. I can live with that, but those brought up on makefiles and command-line compilers probably won’t like it. —Graham _______________________________________________ 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
