new DIP47: Outlining member functions of aggregates

Jesse Phillips Jesse.K.Phillips+D at gmail.com
Sun Sep 8 12:30:25 PDT 2013


On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright 
wrote:
> 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.
>
> http://wiki.dlang.org/DIP47

I am against this proposal. The rationale does not convince me we 
would be getting enough value out of solving this problem.

1. Converting C++ to D

This is the strongest argument. Maybe the issue identified here 
is solved with partial classes (see C#).

2. Having an outline of the code

DDOC already provides this! And any such limitations should be 
fixed. This point has several supporting points.

a. An IDE is not always available to fold code

I never do this, I hate code folding.

b. People read their code just as much in github commits, 
merge/diff windows, emails/chat, etc.

And? I could see some value having a summary for signature 
changes/additions when reviewing commits. For merges this 
proposal just adds one more line of conflict to deal with. 
Brining up emails would suggest that you want someone to write 
down their class signature; instead of having them go to that 
much work I'd rather ask them to generate the docs and email them 
to me. Chat, well I think that is a lost cause (I haven't had any 
code sent to me over chat that I had been glad to have received 
over chat)


I believe requiring the programmer to keep function prototypes in 
sync is a mistake. I also don't think having this be optional is 
addressing the issue of those that are for it.

When C/C++ programmers talk of the problems header files, they 
talk of the problems cause by textual replacements and compiled 
header files. When everyone who doesn't program in C/C++ talk of 
the problems of header files, they talk about the troubles of 
writing prototypes twice.

By providing this feature as an optional statement, you'll be 
left with Manu and his team using it, an no one else touching it 
(Sorry Manu, you're the only one I've seen with a strong 
conviction for it, I know others will use it too).

I realize that we want to make it as painless as possible for 
Remedy to switch from C++ to D (along with the rest of the game 
developers). I'm also really glad about the changes which have 
come from their use/insistence. However I think this is mostly a 
superficial change which will result in a divide in the community 
much like @property.


More information about the Digitalmars-d mailing list