[deleted]
Apple's Module proposal to replace headers for C-based languages [pdf]
141–150 of 187 posts
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#142Since these are not in C++11, we'll have to wait 10 years...
Practically Apple will probably add it to Objective C next year.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#143I don't buy the performance argument: NxM -> N + M only works if every one of the N .c files is including every one of the M .h files. If you're spamming #includes like that, you need to fix your #includes, not redefine the language.
If a .c file includes U x M .h files on average, where U is a number from 0 to 1, then the work we expect to do at compilation time is proportional to U x (N x M). This is still O(N x M).
True, but in my experience U tends to decrease sharply as M increases.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#144I think I'm the only person who likes headers. I'm not overly concerned with compilation times and big-o notation. Computers can compile things really fast nowadays. I'm more concerned with the developer usability benefits & drawbacks of the feature. As somebody who is a polyglot, but spends a large amount of time writing Objective-C, I have come to absolutely love header files. I see header files almost as documenta…
> Computers can compile things really fast nowadays.
Not if you're working on a large project. Firefox takes about 15 minutes to build from scratch on my fast Linux box. Getting that down by a factor of 10 or more would be fantastic.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#145I think I'm the only person who likes headers. I'm not overly concerned with compilation times and big-o notation. Computers can compile things really fast nowadays. I'm more concerned with the developer usability benefits & drawbacks of the feature. As somebody who is a polyglot, but spends a large amount of time writing Objective-C, I have come to absolutely love header files. I see header files almost as documenta…
The headers still exist. This proposal is not about eliminating them. All this proposal does is bundle groups of headers together and give you a simplified way of including them.
If you have a look at the proposed ".map" files, the headers are still fully enumerated. I assume the IDE/debugger will still be able to find definitions in the original header files via the .map files.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#146Earlier quoted context omitted.
Object Pascal did the exact same thing 20 years ago, and it was a language much more influential than Go at its time. So, I don't think Apple programmers had even to look at Go to design this feature.
Yeah. Compile times there were ridiculously fast, bordering on interactive. Go follows the same path. Java has very fast compilation as well, due in no small part to tossing the preprocessor and having fast binary imports.
Part of the advantage of Pascal at the time is that it was created explicitly to allow for fast parsing. C and especially C++ are much harder to parse.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#147I think I'm the only person who likes headers. I'm not overly concerned with compilation times and big-o notation. Computers can compile things really fast nowadays. I'm more concerned with the developer usability benefits & drawbacks of the feature. As somebody who is a polyglot, but spends a large amount of time writing Objective-C, I have come to absolutely love header files. I see header files almost as documenta…
It sounds like you'd really like OCaml's module interface files (.mli). Or, more generally, all of OCaml's module system. It's very well designed and definitely worth checking out.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#148I think I'm the only person who likes headers. I'm not overly concerned with compilation times and big-o notation. Computers can compile things really fast nowadays. I'm more concerned with the developer usability benefits & drawbacks of the feature. As somebody who is a polyglot, but spends a large amount of time writing Objective-C, I have come to absolutely love header files. I see header files almost as documenta…
> Computers can compile things really fast nowadays.
Tell that to my fecking codebase.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#149Earlier quoted context omitted.
Yeah. Compile times there were ridiculously fast, bordering on interactive. Go follows the same path. Java has very fast compilation as well, due in no small part to tossing the preprocessor and having fast binary imports.
Part of the advantage of Pascal at the time is that it was created explicitly to allow for fast parsing. C and especially C++ are much harder to parse.
If I remember correctly, it's a single pass parser, which is why you generally write get to your code upside down.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#150Earlier quoted context omitted.
Well Objective C was a preprocessor extension as this proposal is so it's one and the same. Both are extensions. Yes we all know where vendors that do that got us: -moz-gradient: -ms-gradient: gradient: -webkit-gradient: Oh and Microsoft with their C++ CLR extensions and middle finger to C99.
> Well Objective C was a preprocessor extension as this proposal is so it's one and the same. Both are extensions. This is daft. Objective-C has been implemented using a full-fledged compiler for decades. Is C++ "just an extension to C" because it was once a pre-processor on top of C? Is Common Lisp "an extension to C" because ECL transforms it into C? Utter lunacy. > Yes we all know where vendors that do that got us…
Thanks for linking to Daveed Vandevoorde's proposal. I had no idea that he had originated this concept, else I would have worded the title differently.