new DIP47: Outlining member functions of aggregates

Paolo Invernizzi paolo.invernizzi at gmail.com
Sun Sep 8 23:46:32 PDT 2013


On Monday, 9 September 2013 at 04:00:39 UTC, Manu wrote:
>
> Indeed. These opinions are my own, and I raised it on the merit 
> of our
> experience last weekend in a 48hour game-dev-jam with a few 
> former
> colleagues (including one who still works at Remedy).
> This discussion has come up at remedy in the past, but I don't 
> think this
> is of particular significance to the remedy workflow; the 
> modules were
> small enough to not cause issues, at least not as I left it.
>
> I believe the scenarios I describe are going to be very typical 
> though, at
> least in the game-dev context, particularly when larger volumes 
> of D code
> emerge. I've demonstrated this across 2 separate 48 hour 
> game-jam's now,
> which simulate the environment of a commercial crunch period 
> quite
> faithfully.

I don't believe that typical. We are working with some very big 
modules, and we have _no_ problems at all regarding that aspect.

I think that this is a swift for the discussion: discussing about 
an issue that it is present _today_ in a commercial user of the 
product, or a discussion about an a _potential_ problem.

The worst part of all this mess it is that the proposal ditches 
one of the *strong* selling point of D: no code duplication, use 
documentation if you want an overview.

I also strongly disagree that this way of coding is not typical: 
here at work we are using it without problems with D, and, again, 
DDocs are the right way.

I would also add that also here we have a lot of time pressures 
for the releases... as in every commercial software company I 
know of... ;-P

- Paolo Invernizzi


More information about the Digitalmars-d mailing list