Encapsulation design

[Peanuuutz]

Discussed in https://github.com/akuleshov7/ktoml/discussions/92

^{Originally posted by Peanuuutz January 12, 2022} Currently encapsulation is not present, which is an urgent problem for a widely used application. We should only expose those classes and functions that are necessary for users. This will help users to quickly find what they want, as well as help us develop new features as well as modify existing code without worrying about breaking users' applications.

I'm going to copy what I have done. (Actually these are quite common)

The following are public:

• Entrypoint for serialization and deserialization: Toml. (Consider this suggestion)
• AST: TomlValue(which derives TomlBoolean, TomlLong, TomlBasicString, TomlArray, TomlTable to name a few).
• AST manipulation: like JsonPrimitive.int.
• Exceptions: only sealed TomlEncodingException and TomlDecodingException.

The following are internal:

• Encoders
• Emitters
• Decoders
• Parsers

Also, I suggest separating AST itself and the actual parsing process, like Toml<type> only has content property, while Toml<type>Parser is responsible for parsing and producing it.

[Peanuuutz]

Sync the answer.

New question raised.

[orchestr7]

Sync the answer.

New question raised.

Yes, let it be open. At least we will mark internal methods with opt-in and revise private methods