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