Open timothee-haudebourg opened 3 years ago
Since you seem to be avoiding having any dependencies, you could at least recycle the Key
type used in Object
, rename it to something like SmallString
, make it public, and use it to represent object keys and JsonValue
string variants in a uniform manner.
I see you are planning to use Cow<str>
, but I don't really understand the benefits. I can see some use cases where it would be interesting to have some borrowed keys and values, but on the other hand you lose the small strings optimization. Ideally a Cow<str>
-like structure with SmallString
as owned type would be nice...
Hi,
For now you have two variants in
JsonValue
for strings (Short
andString
). This makes matching against json values tedious, since both variants are semantically equivalent. A better idea would be to use a single variantString(SmallString)
whereSmallString
would be an owned string type similar toSmallVec
. A similar problem occurs insideObject
, where short keys are also optimized in the same way. In myIntoIter
proposal (#191), the short string optimization is lost when items are returned withnext
because of the lack of a properSmallString
type.I have found two crates providing exactly that, both based on
SmallVec
. The first one,smallstring
, mentioned in #191, seems abandoned. Howeversmallstr
seems alive and widely used. Using this would allow you to unify both string variants inJsonValue
and allow theIntoIter
iterator to yield items of type(SmallString, JsonValue)
instead of(String, JsonValue)
.I understand that this would break the compatibility with older versions because the
JsonValue
api would drastically change, but I think it is necessary to have a simpler and more flexible interface (and implementation).