On Tue, Mar 05, 2013 at 06:39:07PM +0100, Rob T wrote: > On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote: > >On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote: > >>+1_000_000_000 > >> > >>Yes please! > >>It's near impossible to get a brief overview of a class at a > >>glance in D! > > > >Exactly for this reason, what about make this way at least the > >recommended way, if not the single one? > > > >What is to lose? As about what to win, basically each .d file will > >carry its .di file (class definition) inside it, and the latter > >can be easily extracted (both visually and automatically). > > > >Just one note: please allow that the private variables of a class > >(those that are not exposed outside the file) be declarable > >outside the main definition of the class, that is with the . > >syntax. This will completely make declaration and implementation > >independent, to the point that the class definition is an > >interface and nothing else. > > This is what I'd like to see happen with modules which seems to be > in agreement with what you are proposing: The module source file > should contain everything needed to automatically generate and > maintain a .di file. There should no need to manually maintain a .di > file.
+1. It should be the compiler's job to export the public API of a given .d module, not the programmer's. By default, it should export only public members. Optionally, we can use UDAs to override compiler defaults in certain cases, where it's necessary. Ideally, such cases will be very rare. > How we accomplish that goal is an implementation detail, however I > fully agree that something needs to be done and it should be done > without any need to manually maintain separate .di files. +1. Separate maintenance of header files in C/C++ has always been a pain and source of inconsistencies. It's one thing when you have a small dedicated team working on the same codebase; I have seen such code in projects that were handed around to different people (due to the usual reasons -- turnover, company reorg, etc.), and inevitably, the headers go out of sync with the implementation files. I've actually seen (and fixed) a case of two C functions that were declared with the same name in two different libraries, and in one module, the wrong library was linked in, thus linking the call to the wrong function, causing strange runtime problems that no amount of staring at the source code would reveal the reason for. The #include was perfectly correct; but the problem was that the declaration was detached from the implementation, so the compiler has no way to check for this kind of problem. Not to mention the silliness of having to copy-n-paste function prototypes in two places -- in this day and age, why are we still promoting such error-prone manual hackish ways of coding? Such things should be automated! D's module system is the beginning of a sane handling of such issues. Let's not go back to the bad ole split header/implementation approach. It should be the compiler's job to extract the public API of a module *automatically*, so that consistency is guaranteed. No room for human error. T -- The best compiler is between your ears. -- Michael Abrash
