On 04/20/2017 04:43 PM, H. S. Teoh via Digitalmars-d wrote:
But if you're printing lots of variables according to a precise template
(e.g., rows of a table or a list of fields), format strings make more
sense, e.g.:
foreach (rec; records) {
writefln("[%8d] %20s %10.3f", rec.id, rec.name, rec.amount);
writefln(" %20s %10s", rec.altName, rec.comment);
writefln(" %20s %6s", rec.address, rec.postalCode);
}
Meh, I'd argue that's just an example of why interpolated strings need
support for formatting:
foreach (rec; records) {
writeln(%"[%8{rec.id}] %20{rec.name } %10.3{rec.amount}");
writeln(%" %20{rec.altName} %10{rec.comment}");
writeln(%" %20{rec.address} %6{rec.postalCode}");
}
And you can't beat this one with interpolated strings:
auto matrix = [
[ 1, 2, 3 ],
[ 4, 5, 6 ],
[ 7, 8, 9 ]
];
writefln("Matrix:\n%([ %(%3d, %) ]%|\n%)", matrix);
That's actually a perfect example of why I don't like printf-style
formatting syntax. I've seen regexes that were more readable.
If you're doing internationalization, though, neither option is a good
one (I gave an example using dates in another post): printf-style
formats have ordering issues (is it year first, then month, then day? Or
month first then day then year? Which argument is which?), and
There's an extension to printf (which, IIRC, D's format supports) that
allows reordering of arguments, much like C#'s format strings, by
specifying the argument numerically. But it's an u-g-l-y syntax. Hard to
remember, too. And why bother referring to the args numerically when you
can have a format string that simply refers to them by name instead (ie,
interpolated strings)?
interpolated strings have the problem of exposing variable names to the
translators (who are probably non-coders), potentially opening up the
possibility of arbitrary code execution via l10n strings. In this case,
it would seem best to have named arguments with format strings.
You're basically describing a templating engine: Which are essentially
just interpolated strings with sandboxing (or alternatively,
interpolated strings are just embedded templating engines).
And yes, I'd rather use a templating engine for non-coder translators
than anything I've seen built-into any programming language: whether
format string or interpolated string. But the last thing I'd hand them
is anything with printf syntax.
Between these textbook cases, though, is plenty of gray areas where it's
debatable whether one syntax is clearly superior over the other(s). And
here, factors of what you're used to, the kind of output you usually
need to produce, etc., all come into play and there doesn't seem to be a
clear one-size-fits-all.
When I see lots of options that are all basically the same thing, but
each have their own little limitations and drawbacks (thus limiting each
one's applicability to mere subsections of the overall problem
domain)...well...that really bugs the shit out of me. ;) It's a big,
loud, flashing sign that everybody's designs have gotten things wrong
and none of them have quite hit the right mark.
It makes me want to consolidate: Break down the limitations that divide
the current options, reach the true "core" of the problem, and show that
they're not really all separate tools, but mere approximations of the
proper generalization that simply needed to be found and brought out.
It's analogous to mathematical models: When the equations are complex
and special-cased (like the rift between Newtonian physics and quantum
physics) - that's how they know they probably got the model wrong. When
they wind up with something simple, elegant and just-works, that's a
sign they may be on the right track. Luckily, good general-purpose tools
are a lot easier to come up with than unified field theory. ;) If
scientists acted like programmers, the solar system model would still be
stuck at the pre-Copernicus "All those planets have VERY COMPLEX
movements! Very, VERY complex!! Good thing we have this big ol' toolbox
with all the many, many tools involved in modeling all those
complexities and special cases!"
Basically, I'm the antithesis of a polyglot programmer :)
