best/proper way to declare constants ?

[someone]

On Thursday, 5 August 2021 at 17:12:13 UTC, H. S. Teoh wrote:
> [...]
>
> I'd say if the performance hit isn't noticeably bad right now, 
> don't worry too much about it. You can always replace it later. 
> One thing I really like about D is how easily refactorable D 
> code tends to be. If you structure your code in a way that 
> keeps separate concerns apart (and D features like 
> metaprogramming really help with this), replacing your 
> implementation choice with something else

Granted, I'll be taking your advice :)

> often turns out to be surprisingly simple.

Although I have very little experience with D, I second this: 
refactoring, even huge refactors, proved to be far more 
straightforward than I expected.

> But if you expect to process very large data files at 
> compile-time

Not at all, very tiny files, what you saw on my examples, 10 
times that at the very very far end; but more probably no more 
than 10/15 exchanges meaning an AA length 15, period.

> I'd say consider generating the classes via a utility D program 
> that emits D code as a separate step.  In one of my projects I 
> have a whole bunch of 3D model files that I need to convert 
> into a format more suitable for use at runtime.  I eventually 
> opted to do this as a separate step from the main compilation: 
> a helper utility to parse the files, massage the data, then 
> spit out a .d file with the right definitions (including 
> embedded array literals for binary data), then compile that 
> into the main program.  Since the data rarely changes, it's a 
> waste of time to keep regenerating it every time I recompile; 
> keeping it as a separate step means I only need to rerun the 
> helper utility when the data actually changes as opposed to 
> every single time I change 1 line of code.

I am very used to this mainly on SQL-Server with TransactSQL 
(horrible "language" to say the least): lots of functionallity 
automatically-generated from XML/XSD file definitions to 
transactSQL via XSLT transformations, all within SQL-Sever itself 
(the NET framework has superb handling of everything XML/XSD/XSLT 
related) ... think of it like code-on-demand or code-on-the-fly. 
In the end this approach gives me lots of flexibility and allows 
me to do things almost-unthinkable in transactSQL; key here is 
the ability to SQL-Server to easily invoke external code, and 
this is what makes me wonder what a super-combo D as a first-tier 
language on postgreSQL could achieve ... drooling here :)