JsonRazor 1.5.0

1.5.0:

Changes to existing code:

• Updated method docs for conversion methods in AbstractString and JsonValue, JsonArray & JsonObject copy constructors, and some other methods.
• ToJsonObject(IEnumerable<JsonToken>) extension method now does not accepts nulls.
• ToJsonObject(IEnumerable<KeyValuePair<string,string>>) extension method now does not allow null keys.
• ToJsonArray(IEnumerable<JsonObject> or IEnumerable<JsonArray>) extension methods now accept null items.
• Serialization.TokensFromTypeReadable() method has been renamed to TokensReadable(). My bad, it havent even taken type argument.
• AbstractString's ToInt32(), ToInt64() and ToSingle() methods have been renamed to their respective type keyword (ToInt(), ToLong() and ToFloat()), what matches with style that JsonToken/JsonValue use.
• One of bool flags in JsonStream.StreamFile() (caching, IIRC), was removed. It made no further sense. Also current StreamFile's caching strategy is to always cache tokens, regardless of Include() being called or not. For scenarios involving using IToken out of enumeration use DrawTokens() instead.
• IToken.Include() will now throw InvalidOperationException when called after enumerator has been disposed. Usually rewording of linq methods helps resolve this issue.
• Both JsonStream's StreamFile() and StreamConverted() will throw InvalidOperationException when being enumerated again with captured enumerable instance.
• Usage of IToken.QueryTokens() for json object is discouraged. Use indexer instead (it's also a lot more sensible).
• IToken.Include() got bool argument with default value = true, which doesn't alter current behaviour in any way.

Fixes:

• GetHashCode() would throw exceptions in certain cases.
• AbstractString[int] wouldn't throw IndexOutOfRangeException in some cases.
• AbstractString.ToInt64() and ToInt32() wouldn't parse consistently with JsonValue.IntStyle.
• When parsed with Json.ValueCorrectnessChecks flag set, incorrect and quoted value would pass validation in some cases. Also string detection via detectString args would incorrectly behave in such cases.
• JsonToken and JsonValue SetValue() methods would sometimes misbehave in terms of quotes and null replacement. Currently null string is converted to runtime null only if it was written without quotes, whereas quoted or "" should remain unchanged.
• JsonToken or JsonValue, produced by IToken.Convert(), Value or ToString() would in rare cases violate said rules.
• Both JsonStream.StreamFile() and StreamConverted() wouldn't clear cache when enumeration wasn't full.
• Parsing from StreamReader in some cases would cause stream retention that prevented garbage collection. That issue has been resolved for fully parsed source. In other case Dispose() static method should be called. This issue should be addressed in future releases.
• JsonStream.StreamFile() would behave unpredictable in some cases.
• IToken.Include() wouln't cause parsing to happen in some cases.

New features:

• IJsonNameStyle interface, that you may implement to easily convert member names to any custom format. Pass an instance to Deserialization' or Serialization' NameStyle property. [JsonName] has a precedence over style, so backward compatibility with older model definitions is maintained. Member names are computed only once for given type. Also constructor parameter names remain untouched.
• Serialization basic support for writing JsonComposite that is in object type field or property as part of regular model. This is complementary functionality to deserialization of undefined type.
• JsonToken.ToTokenDictionary() extension method, that takes all object's tokens and puts in dictionary.
• JsonToken.Add(JsonToken) method, that allows calling Append() from JsonToken type.
• JsonToken.ValueCount virtual property to ease access to array one.
• JsonToken.From(StreamReader) that returns unparsed token, just like string equivalent does.
• JsonToken.Read(string) that returns parsed token, just like stream equivalent does.
• ICommonToken interface, that both JsonToken and IToken implement (some of members, like indexer, explicitly), so that base operations could be performed interchangeably. Take into account that IToken needs to be casted.
• IToken.Included() method, that does exactly what Include() does, but returns passed value of included (true by default). It can be used conveniently inside lambda expressions with predicates, so calls like Where(t ⇒ predicate).Select(t ⇒ t.Include()) could be shorten to Where(t ⇒ predicate ? t.Included() : false), or even Where(t ⇒ predicate && t.Included()).
• JsonStream.DrawTokens() method that is designed purely to return tokens ready for operations outside of enumerable processing. In order to parse token it is advised to use Include() or Included() method. Alternatively, Count and ValueCount properties will cause immediate parsing, but may mess up caching strategy (ie. when Count is used for testing) - in such cases passing false to Include() or Included() after calling Count will cause token to be normally cached.
• New compilation target: .NET Core 2.1, and AbstractString.ToSpan() method.

Performance:

• Reduced number of allocations for IToken deserialization under .NET Core 2.1
• Reduced size of internal allocations made by CachingSerializer.
• Reduced size of assembly around 2kb. Enumerator allocations done by JsonComposite.AsLazy() and JsonArray.Values() were reduced.
• Array deserialization allocates less garbage.
• JsonToken.Write() causes less allocations. Also its parformance for deeply nested structures improved marginally.
• Object hashing got more attention (I was bout to delete this, coz it was purely useless). But before i did that, whole hashing was rewritten using different algorithm. Both hashing process and lookup time decreased around 20-30%, memory usage decreased ~15%. Also JsonObject instance size went down. So, according to my tests, with around 50 tokens inside object, both execution time of full lookup using linear search, and full lookup using hashing + hashing time were approximately equal, (in some cases even 40 was faster for hashing), and starting from ~60 keys hashing is consistently faster. So it seems that hashing has its worth. Altho it may speed up ie. deserialization in some cases, it isn't performed by default.
• Deserialization using CachingDeserializer with object IToken should be noticeably faster, probably around 10-20%.
• Regular parsing from StreamReader should be marginally faster. Also reduced number of allocations.

Next versions may target reading and writing of comments alongside json token hierarchy, default value serialization behaviour (0, false), enum serialization format (text / number) and further performance improvements. There are also things i'd try out but don't have specified desings in mind.