> I felt like I had to write unnecessary 'glue' with header files
Headers are a feature, not a bug. They're the API. They help document the API and also keep it separate from the implementation.
Headers are a feature, not a bug. They're the API. They help document the API and also keep it separate from the implementation.
Xcode presents the equivalent of a “header” when you follow a symbol to a framework you don’t have the source for… it’s a swift file full of definitions only and no implementations. The compiler emits this for you automatically as a .swiftinterface file
> or keep things non-`public`
I definitely am a swift developer that would complain about this. It’s way too easy to be cavalier about using the “public” keyword and making things part of the public API when they probably shouldn’t be. It’s like engineers have muscle memory from Java and just type “public class” without really questioning why first.
It's so incredibly slow, though, which is frustrating. It would be ok if only this were as instantaneous as checking a header file.
Ironically, almost everything about "Swift" is slower than Objective-C.
That problem was already solved with header files; trivial to split interface from implementation, they’re just two different files. But sometime around the 90s, probably Java and this was deemed inconvenient. Now we’re trying to reinvent that same pattern
This is a good pattern for some cases, like the public members of a package. However, I love that I don’t need to do this for every class I write.
And if you do use this approach, at least swift will emit a compile error if your protocol and implementation signatures don’t match.
ObjC will happily compile if your header is missing an implementation and crash at runtime.
Headers are such an idiotic design, over-abstraction harms locality of reasoning.
Why parse out a whole C file when you can get the only bits that matter for compiling your file from a 30 line header?