Thanks Jim. I've had reasonable success
getting the float %-formatting cases covered by the new
FloatFormatter (to save us two skips). I'll try an
IntegerFormatter along the same lines, to fix the oddness I noted,
and make the refactoring neat.
I've no intention of replacing the switch here, but I'll look out
where I may be better off using one to choose between actions. I
understand how it compiles.
I agree non-BMP codepoints would not be an issue unless maybe you
put one where a formatting type was expected.
On 05/05/2014 00:16, Jim Baker wrote:
I'm glad you are looking at this! In looking at
StringFormatter, I agree with your refactoring plan.
StringFormatter grew by accretion, and at this point it's
quite hard to follow.
The current method StringFormatter of using a driving
switch statement for its format string interpreter remains the
fastest way to dispatch in Java. However, it will be both more
inlineable by the JVM and more testable by us if we breaking
out each chunk of work into its own small method.
Another thing: although peek/push/pop mechanism in
conjunction with index is not codepoint aware and just uses
format.charAt, this doesn't matter in the end. This is because
the format characters are all in the BMP - and in fact are
ASCII. So we can continue to use charAt. However, I would
recommend also splitting this functionality into a small
helper class, for the above inlining/testing reasons.