sync human-readable value

[fawdlstty]

fix #8438

[fawdlstty]

@jtdavis777 @aardappel Hello, could you spare some time to review this code?

[jtdavis777]

this change seems fine... I'm not convinced it closes the original ticket out, but I don't see why adding an additional function to get more info would be a bad thing.

I wasn't really able to follow the discussion on the original issue.

[fawdlstty]

Sorry, I forgot to explain the reason for this modification. Here I would like to add:

In the serde repository, the is_human_readable function is defined as default true (which means that if this function is not overridden, its return value will be true).

The problem with flexbuffers is that if no compatible features are defined, the value of is_human_readable will be false. If only FlexbufferSerializer is defined, it works fine. Because it correctly utilizes the features.

see:https://github.com/google/flatbuffers/blob/master/rust/flexbuffers/src/builder/ser.rs#L219

However, the struct MapKeySerializer does not override this feature, which results in the "is_human_readable" value being true (using the default value from the serde library), which is different from FlexbufferSerializer.

As of now, it cannot be said that the above code has any problems. However, at present, the only deserialization type available is Reader.

see: https://github.com/google/flatbuffers/blob/master/rust/flexbuffers/src/reader/de.rs#L162

It redefined the "is_human_readable" function, with the return value determined by the "features" definition, and the default value is false.

The problem here is that, by default, the value of is_human_readable is true during serialization, but it is false during deserialization.

For the serialization and deserialization of the same data sequence, the value of is_human_readable must be the same in order to conform to the conventional definition.

NOTE: The above is my personal understanding, but at the same time I don't think there is any problem with the original implementation. I hope that experienced Rust developers can judge whether the above modifications are appropriate.

If these characteristics were deliberately designed, then perhaps adding more explanations would be more beneficial. (At least I have a misunderstanding about this.)

[jtdavis777]

I really appreciate your detailed message and I am good with this PR. However, if possible I think a test would be great.

[fawdlstty]

I'm sorry, I think it's difficult to add the test. Regardless of the value of is_ruman_deadable, whether it actually causes problems is determined by the user's own implementation of the serialize or deserialize feature. The above modifications are only intended to make the definition more "conventional" or "unambiguous"