On Jun 17, 2015, at 00:56 , Graham Cox <graham....@bigpond.com> wrote: > > 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 already done in Swift 2. While you’re editing in the one pane, the Counterparts setting in the assistant pane (which in Obj-C shows the .h when you edit the .m) shows exactly this view, along with documentation (///) comments. It actually shows public and internal API within a module (basically the same thing), but I assume when used cross-module it shows only public API, but I haven’t had a chance to try that yet (though this is what Command-click on Cocoa APIs shows you, so I assume it works the same). > 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. I was being a little bit facetious. It’s minor when you’re first writing the class, but if you’re creating a lot of classes at one time (say, converting code from another language), it gets very tedious very quickly. It’s also one of the “I can’t believe the IDE doesn’t do that for you” features that newcomers to Obj-C complained about in the dev forums *a lot*. _______________________________________________ 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
