peteroupc/CBOR

Improving FromObject and ToObject

peteroupc opened this issue · 4 comments

peteroupc commented

Currently, FromObject and ToObject (the latter of which was added in version 3.4.0-alpha1, a prerelease) support converting CBOR objects to and from a wide variety of natively supported types, as well as to and from arbitrary classes known as POD classes (better known as POCOs in .NET or POJOs in Java).

However, both methods currently leave much to be desired. For example, there are certain inconsistencies between FromObject and ToObject, as well as between the .NET and Java versions of both methods. Some of these inconsistencies have to remain in version 3.x for backward compatibility. These inconsistencies and other issues are further explained in the documentation:

There are important questions that should be answered to help improve FromObject and ToObject in version 4.0 and possibly in version 3.4, taking into consideration how both methods currently behave.

  • What data types (source and destination) should both methods support?
  • How should both methods convert POD classes to and from CBOR objects in .NET? In Java?
  • What source-type-to-destination-type conversions should ToObject support?
  • How should the ToObject method behave if data is of the wrong type (e.g., when the source is a string but the destination is a number) or if data is a number that's unsupported for the destination type (e.g., how should the converter behave if the source is say 67.59, but the destination stores only integers? should the converter round to the nearest number, truncate fractions, raise an exception, something else?)
  • How can FromObject and ToObject be designed for better forward compatibility in version 4.0 and later?
peteroupc commented

While working on this, I have managed to answer much of the questions in the opening thread. But at least one question remains. How should chars be serialized by default in my library's FromObject and ToObject methods? There are several approaches.

  • As integers, the approach seen in Json.NET.
  • As text strings, the approach seen in GSON and the current version of my library. The disadvantage is that surrogate code points can't be represented using this approach.
  • As integers tagged with a yet-to-be-defined CBOR tag.

Jackson and other libraries may also take different approaches to serializing chars. (I have come up with a way that applications can override the default behavior, using CBORTypeMapper.)

charlesroddie commented

Hi @peteroupc . Trying this library out today. The API is good.

I see that there is a major change to the storing of chars in 4.0.0-alpha1 .

Can there be a corresponding AsChar() instance method?

Also small request: could the xml documentation on a CBORObject be shortened? It tends to fill the whole screen on hover. First couple of sentences would do.

Thanks!

peteroupc commented

Hi @peteroupc . Trying this library out today. The API is good.

I see that there is a major change to the storing of chars in 4.0.0-alpha1 .

Can there be a corresponding AsChar() instance method?

Also small request: could the xml documentation on a CBORObject be shortened? It tends to fill the whole screen on hover. First couple of sentences would do.

Thanks!

AsChar() is not planned; note that char is a UTF-16 code unit, not a Unicode code point (which covers more values than a char can cover), and having AsChar() is not expected to be used as often as, say, AsString() or AsInt32(). Moreover, there is an easy alternative: ToObject<char>().

charlesroddie commented

OK I assumed it would change from x.ToObject<char>() to (char) x.ToObject<int>() because of the recent change to encode chars as ints.