<div dir="ltr">Missed the action...<div><br></div><div>Well it's clear this is not a popular proposal.</div><div>And even to me personally, it's certainly not of critical importance. If there was a single thing I'd like to see *DONE* in D, it would be temporary/r-value->ref args, without question (really, really annoying to work around).</div>
<div><br></div><div>For the record, I tend to agree with the arguments of many in the 'against' camp *from a purist point of view*, but the problem remains, and the reason I raised it; this has demonstrated to me and my colleagues on a number of occasions that it is a consistent productivity hindrance.</div>
<div>I guess a significant reason my experience seems to differ from many(/most) on this forum, is that they're not in the business of banging out quick throw-away commercial code.<br></div><div>The practical reality in my experience in the games industry is this:</div>
<div> - Some (perhaps small) percentage of code is tech/foundation code. It is carefully authored, but still typically documented only of the class outline in the header file isn't already self-explanatory (I'm a big fan of self-documenting code). It is to be re-used.</div>
<div> - Much (perhaps most) code is rudimentary logic and glue code, or 'game code' as we call it. This tends to be code that is written by more inexperienced programmers and written to tight schedules. It is almost never documented (apart from the occasional inline comments), rarely conforms to some spec (unless it's implementing from foundational interface), and usually exists to serve only the life of this one very specific project, ie, throw-away. It is also almost always logic-intensive code, riddled with switch/if/else constructs that take an awful lot of vertical space, which further magnifies the problem of inline function definitions breaking up the readability of the class outline.</div>
<div><br></div><div>Now further, from an absolutely practical point of view, the time that someone unfamiliar with this code has to deal with it in the first place is very likely at 11pm the night before the publisher is demanding a build so they can show it to a bunch of arseholes in fancy suits who will decide if they're going to pay us or not.<br>
</div><div>In C++ there is a very useful tool for unfamiliar programmers to get a good brief overview of the code before they go hacking at it, that is the class outline.</div><div>We've lost that. And I have demonstrably missed it.</div>
<div><br></div><div><div>People make claims like "write better code, split it up better, document your code better, use the IDE folding", blah blah, but it's simply not the practical reality. The budget and schedule does not typically allow for careful consideration, design, and documentation of such throw away code which glues the project together.</div>
<div>The code is what it is, and whether it's written in C++, or D, or lua, it's probably not going to change the nature of this huge volume of crappy code.</div><div>Code folding doesn't work in foreign editors, communication tools, diff windows; code reviews become more time consuming to approve, and I don't know many programmers that like/use it regardless, even if it may help in some occasions.</div>
<div>I think it's bat-shit-crazy to rely on a tool to simply make code readable and easy to understand for a start. I also personally feel code folding alienates me from the code I'm writing. As an author, you quickly gain a feel for the layout of your source file; the flow and shape of the code across the file is kinda picturesque. For me personally, code folding ruins that relationship with my code, and I don't like it. It makes it harder for me to sweep through my file and quickly locate the points of interest that I'm working through. So if I'm not using it in my own code, but I'm required to use it to understand someone else's code... there's a bit of a conflict of interest there.</div>
</div><div><br></div><div>If I'm one of very few voices in favour of class outlines, I'm going to suggest letting this argument sleep until other more serious issues are resolved which people have been waiting on for ages.</div>
<div>I certainly want r-values -> ref args to work much more.</div><div><br></div><div>Keep in mind, I raised this debate as a practical account of last weekend, among a bunch of other issues which were certainly more significant than this one, but this seemed to capture the most attention.</div>
<div>It's not the first time it's come up and it'll be back again I'm sure :)<br></div><div><br></div><div>I support this DIP, obviously, but I'd suggest perhaps a conservative restriction that definitions should only be allowed to appear within the same module as the declaration. This would seem to simplify things like mangling issues and access rights. In my own use case, I have no reason to spread definitions across files. I just want to see class outlines clearly summarised at the top of the file. This saves time, and time is money.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 8 September 2013 03:00, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Outlining of member functions is the practice of placing the declaration of a member function in the struct/class/union, and placing the definition of it at global scope in the module or even in another module.<br>

<br>
<a href="http://wiki.dlang.org/DIP47" target="_blank">http://wiki.dlang.org/DIP47</a><br>
</blockquote></div><br></div>