Not sure how to translate this C++ variable to D.

[Ali Çehreli via Digitalmars-d-learn]

On 03/15/2016 07:29 AM, WhatMeWorry wrote:

 >> SpriteRenderer Renderer;  // Although, I would name it 'renderer'

 > Ok. I was trying something more D like, by doing:
 >
 > SpriteRenderer Renderer = new SpriteRenderer();

That would work if the variable were const or immutable and if 
everything needed to execute the expression were available at compile time:

const(SpriteRenderer) renderer = new SpriteRenderer();
immutable(SpriteRenderer) renderer = new SpriteRenderer();

(Note: Associative arrays literals still cannot be initialized with that 
syntax and arrays may have performance implications.)

For mutable variables and for anything in general, module variables can 
be initialized in 'statit this()' and 'shared static this()' scopes:

static this() {
     renderer = new SpriteRenderer();
}

The difference is that 'static this()' is executed at runtime before any 
code in the module gets executed. It is like the constructor of the 
whole module. (You can have many disjoint 'static this()' blocks, which 
would all get executed.)

 > In large projects with 1000s of
 > line of code and many many modules, classes, structs, and functions; is
 > it probably true that most of the time the vast majority of variables
 > are going to be inside one of above constructs?

In D, everything will be inside one of those constructs because you 
included "modules". :) Like many modern languages, D lacks a global 
scope. Although we are advised to use the global scope much less in 
general, it is less applicable to D. In other words, it is fine to have 
module variables. For example, if a module consists of a single class, 
there wouldn't be any difference between making a variable class-static 
or module-scope. (Others, please correct me if you know any differences.)

 > And is there a name for the variables that fall outside of the above
 > constructs?

I think module-scope or module would work.

 > I see so many tiny code snippets in books and docs, that when I do look
 > at large dub/github projects, I'm not sure how to organize the "stuff"
 > that slops over the edges.

That's always hard :) but "cohesion" seems to be a winning goal: program 
constructs should have little responsibilities.

Ali