dawid.weiss at gmail.com
Thu Sep 15 07:21:01 UTC 2016
> Console is supposed to be a "char/String" based class, "encoding" really
> should have no business here in its api.
While I agree with your concerns about the functional side of the API,
I disagree about this method having no practical use. I can give you a
concrete example. The use case that we had was to check whether the
"terminal" (console) would be able to handle non-ASCII characters. A
Writer doesn't tell you anything. An encoding does provide at least
some confidence that certain characters will be translated properly --
if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't
get displayed for sure. This doesn't mean 100% confidence in actual
glyph rendering of course, but it's a cheap and safe sanity check of
the terminal's capabilities.
An (undocumented) proprietary property? Sure, but I really don't see
the reason why this shouldn't be in the API, unless you know of
terminals that handle Unicode-based streams directly (in which case
the encoding method would simply return UTF32).
More information about the core-libs-dev