On Monday, 20 February 2012 at 21:02:21 UTC, Andrei Alexandrescu
wrote:
On 2/20/12 2:01 PM, foobar wrote:
Seconded. Reflection seems a much better solution for this.
Absolutely.
The i18n table would map (exception type) -> (language, format
string)
and the i18n formatter would use reflection to map field
values to the
format string.
a format string would be e.g. "File {filename} not found" and
the
formatter would replace {filename} with
e.class.getField("filename").
This does not require any modifications to the exception
mechanism.
Yah, but the reflection engine would have to present RTTI in a
uniform manner... such as, Variant[string]. Bane of my life:
I'm always right :o).
Andrei
Unfortunately you aren't :)
The Variant[string] approach causes coupling between two separate
concerns: i18n and error handling. Reflection does *not* cause
such coupling. More over, Reflection is a general language
mechanism with many benefits such as allowing the user to use the
i18n library with other non exception types.
Lastly, good RTTI is hardly a simple Variant[string]. Java for
instance has pretty good RTTI API whereas the c++ one is horrible
(and incomplete).
Conclusion - *not* the same thing!
