Le 20/02/2012 19:02, Andrei Alexandrescu a écrit :
On 2/20/12 11:28 AM, Jose Armando Garcia wrote:
On Mon, Feb 20, 2012 at 2:37 PM, Andrei Alexandrescu
<[email protected] <mailto:[email protected]>>
wrote:
On 2/20/12 10:16 AM, Nick Sabalausky wrote:
"Andrei Alexandrescu"<[email protected]
<mailto:[email protected]>> wrote in message
news:jhtq31$u8q$1@digitalmars.__com...
Again, I think this thread clarified we need the
"Variant[string] info;"
member however we define the hierarchy.
I disagree. I don't see a need for that.
How would we address custom formatting of e.g. error messages?
This may not be D. Gettext says to solve it as follow:
throw new Exception(gettext("Cool English message at
%s.").format(DateTime.now()))
The gettext "compiler" goes through the code an generates all the
strings that need to be localized. The translation teams modifies those
string and you store them in file/map for that language. At runtime the
i18n library turns gettext(...) into a query into that map and returns
the actual localized string. There is a map for the entire process.
Localization can also be disable at compile time by making gettext a
template and generating a "noop" for that operation.
So this moves formatting from the catch point to the throw point. That's
fine, but it forces the formatting effort upfront even when the message
is not actually used and leads to duplication because each call site
would need to provide the message entirely. I think it's worth
investigating formatting at the catch site.
This is not the way we want to go. You have a piece of code to describe
what the problem is, another to descide what to do with that problem and
again another to do something that may go wrong.
Formatting is an error handling problem, and so formatting at the throw
point is a bad separation of concerns.
Plus, the way you want to format stuff is likely to depend on the
application.
