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 :)
