GeezerVison

@muga
I also feel getXXX and toXXX are confusing. And also toString produces JSON string that produces double quoted strings even if user need to get a string value. There are lot of confusing points.

How about renaming these methods as follows?:

• (round)toXXX (with truncation or rounding)
• (cast)asXXX throws Exception (checked cast)
• toJSON (produces json string. The same with the current implementation of toString)

Then remove getXXX methods.

How about this simply?

• rename NumberValue#toXxx() methods to NumberValue#roundToXxx()

I think it's a possible idea to separate toJson from toString. However, because some values are not compatible with JSON (non-string keys of a map, ExtensionValue, floating point values, etc.), we would need another class like ValueToJsonPacker that converts Value to JSON so that the conversion behavior can be configurable using the constructor of the packer class.

@frsyuki
If we recommend to use Value.getXXX to extract values, simply renaming toXXX -> roundToXXX is better.

My concern on StringValue.toString is it always returns double quoted value in generating string messages with StringValue.

Using double quoted string looks good for distinguishing StringValue "1" and FloatValue 1 when debugging.

OK. I'll go with roundToXXX, getXXX and toString. toJSON should be implemented in another class as @frsyuki said.

A problem is getting float value has no good name like roundToXXX.

How about using asXXX for truncation and rounding (e.g., asInt, asFloat, etc., rather than roundToInt, roundToFloat?).

If we use asXXX, we can simply say representing this value as XXX type.

mmm. But asXXXValue is already used for converting Value types. So castAsXXX might be better.

Merged. Will add test codes and further internal improvement in another PR.

Why don't you use roundToXxx? I think that castAsXxx assumes that users understand the actual implementation the methods. If we assume that users don't have to know the actual implementation, I think castToXxx is confusing because I don't know whether it throws exceptions or not. For example, Double v = 1.1; Integer iv = (Integer) v; throws an exception in Java. So, "cast" doesn't always implies rounding.

In my opinion, roundToFloat / roundToDouble is correct name because it actually can rounding.

@xerial How about this radical idea?:

• Concept:
  • toXxx and asXxx are the type casting methods.
  • toXxx methods may lose some information but never throws exceptions.
  • asXxx methods don't lose information but might throw exceptions. Perhaps it's good idea to make them checked-exception so that difference of toXxx and asXxx becomes very clear.
• Implementation:
  • a) change IntegerValue#getXxx() to asXxx()
  • b) change NumberValue#castAsXxx() to toXxx() including toFloat() and toDouble()
  • c) change RawValue#getString() to asString(), RawValue#getByteBuffer() to asByteBuffer(), RawValue#getByteArray() to asByteArray()
  • d) change ListValue#list() to asList(), MapValue#map() to asMap()
  • e) change BooleanValue#getBoolean() to asBoolean()
  • f) remove StringValue#stringValue()
  • g) change StringValue#toString() so that it doesn't add double quotes
  • h) add String Value#toJson(). This implementation is same with current #toString(). So, it's easy to implement.
  • i) add void Value#toJson(JsonPacker) in the future so that we can customize behavior and improve performance if necessary. For example, "how to convert BinaryValue to JSON?", "how to convert ExntesionValue to JSON?", "how to convert FloatValue to JSON?", "how to handle non-string keys in a MapValue?"

With this idea, you can achieve short names and consistent concept at the same time.

@frsyuki
If we do h) (toString -> toJson), I agree with your idea:

• toXXX (may lose information with casting, but throws no exception)
• asXXX (may throw exception)

@frsyuki
But NumberValue.asXXX is already used for Value.asXXXValue. That was why I choose castAsXXX to distinguish methods that produce native values and msgpack Values.

@xerial I think that Value.asAbcValue methods are also a kind of asXxx methods because it doesn't lose information, may throw exception, and Xxx is the returning class name.
(I edited above comment. toJson is not f but h. please check on github)

If having asInt and asIntegerValue is OK, there would be no problem.