Added support for deserializing properties/fields of collection interfaces #3
Conversation
…face types for collections that were already supported (Lists and Dictionaries). ISet<T> and non-generic IDictionary are still unsupported.
|
Thanks! Personally I would cache the |
|
No, not yet. I will take a look at the performance next week. |
… a generic collection type that implements an interface (this can be used to for other generic types, too)
|
Did you get any timing difference? |
|
Also instead of |
|
In my own project I'm using C#7 System.ValueTuple (which is a struct), but I don't know what the minimum c# / .net version is that should be supported. I found that with some additions, it could work for .NET 4.0, but I'm not sure about IDE support. I'll just add a custom struct instead to be sure I'm not using language features that are 'too new'. |
|
(I have not tested if caching improves performance, but I'm quite confident a dictionary lookup will be faster than repeated calls to MakeGenericType. However, it will only make a difference when the type is used more than once, of course. I could also make the dictionary creation lazy, as it won't always be used. ) |
|
Note: |
…at are not explicitly supported.
# Conflicts: # fastBinaryJSON/BJSON.cs # fastBinaryJSON/Reflection.cs
|
Sorry for the delay in resolving the conflicts. I switched jobs in the meantime and just found I had something unfinished. (I could not test if my changes still work after any changes on master in the meantime, but I did my best adjusting it just looking at the code ) |
No description provided.