4 ms·

> 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 i

by lapcat 3y ago

> 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.

glhaynes 3y ago
Objective-C programmers say this, but I note that I've never once heard a Swift developer complain that it's too hard to discover API interface or keep things non-`public`.
- jshier 3y ago
  Only access control I wish Swift had is typeprivate so I could hide private things but make them available for subclasses (or perhaps protocol conformers). Unfortunately Apple has only added a package level so far, which seems fairly useless (you're either too big for it to be useful or too small to need it). Obj-C didn't really have ACLs at all, you just hid stuff in interfaces. Once found, those interfaces were no protection at all.
- ninkendo 3y ago
  > never once heard a Swift developer complain that it's too hard to discover API interface 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.
  - lapcat 3y ago
    > The compiler emits this for you automatically as a .swiftinterface file 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.
- ultrarunner 3y ago
  Everyone's brain is probably different, but when I first started writing swift I definitely missed header files. When I switch back from a c project I miss them again.
- pasc1878 3y ago
  IDEs have improved so integration of Swift and searching is easy. Objective-C now could do without headers but I used it 25 years ago and having headers made life easier.
- itsthejb 3y ago
  In my current and previous job, we talked about (and partially implemented) low level “contract” modules in order to avoid linking (and building) the entire module in order to share behaviour 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
myfavoritedog 3y ago
Any time a language forces you to create boilerplate that could be autogenerated by your toolchain, it's not a feature.
newZWhoDis 3y ago
You don’t need “the API” in another file. Headers are such an idiotic design, over-abstraction harms locality of reasoning.
- MBCook 3y ago
  They made a TON of sense when memory was very limited. 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?
  - pjmlp 3y ago
    Except languages with modules already existed, in systems even more constrained memory predating C's invention.
turdprincess 3y ago
Swift allows you to program using “headers” - just have a protocol and an implementation, even in separate files if you want. 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.
sbjs 3y ago
TypeScript is no headache for me and has no header files.

by lapcat 3y ago

> 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.

glhaynes 3y ago

Objective-C programmers say this, but I note that I've never once heard a Swift developer complain that it's too hard to discover API interface or keep things non-`public`.

jshier 3y ago
Only access control I wish Swift had is typeprivate so I could hide private things but make them available for subclasses (or perhaps protocol conformers). Unfortunately Apple has only added a package level so far, which seems fairly useless (you're either too big for it to be useful or too small to need it). Obj-C didn't really have ACLs at all, you just hid stuff in interfaces. Once found, those interfaces were no protection at all.
ninkendo 3y ago
> never once heard a Swift developer complain that it's too hard to discover API interface 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.
- lapcat 3y ago
  > The compiler emits this for you automatically as a .swiftinterface file 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.
ultrarunner 3y ago
Everyone's brain is probably different, but when I first started writing swift I definitely missed header files. When I switch back from a c project I miss them again.
pasc1878 3y ago
IDEs have improved so integration of Swift and searching is easy. Objective-C now could do without headers but I used it 25 years ago and having headers made life easier.
itsthejb 3y ago
In my current and previous job, we talked about (and partially implemented) low level “contract” modules in order to avoid linking (and building) the entire module in order to share behaviour 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

myfavoritedog 3y ago

Any time a language forces you to create boilerplate that could be autogenerated by your toolchain, it's not a feature.

newZWhoDis 3y ago

You don’t need “the API” in another file. Headers are such an idiotic design, over-abstraction harms locality of reasoning.

MBCook 3y ago
They made a TON of sense when memory was very limited. 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?
- pjmlp 3y ago
  Except languages with modules already existed, in systems even more constrained memory predating C's invention.

turdprincess 3y ago

Swift allows you to program using “headers” - just have a protocol and an implementation, even in separate files if you want. 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.

sbjs 3y ago

TypeScript is no headache for me and has no header files.