API whishlist

[nikeee]

Assume we can do breaking changes, what could we do?

• How about every response of the rich client is also a readonly-dictionary that contains all the original values? Pros? Cons? (Rel.: #26)
  • Pros:
    • Prevents #25
    • Access to raw data, if needed
  • Cons:
    • The data is hold multiple times, slightly higher memory consumption
    • Some users might rely too heavily on them (or in the wrong cases)

Implementation couold look like this:

class Response : IReadOnlyDictionary<string, string>
{
    private readonly IReadOnlyDictionary<string, string> _rawFields; // init via setter mechanism during response processing
    // ...
    // Implement indexer with getter only, just returning _rawFields's entry
    // ...
}

• How about generating the data classes in the Specialzed-Namespace? Pros? Cons?
  • Pros:
    • Maybe (tm) faster de-serialization as we could define a general setter method that calls hand-written converters based on an auto-generated switch-statement. No dynamic invocations needed.
    • Debugging is easier for single responses
    • We might share/maintain the declaration with https://github.com/ReSpeak/tsdeclarations
  • Cons:
    • Generating code before compilation can introduce (caching) errors
    • Generating code requires a generator... which has to run on all plattforms that can compile C#. Maybe use a sub-project? Or a Roslyn-API?
• Can we somehow benefit from C# 7.x/8 features? Span<T>, Memory<T>, Ref-Returns/In-Parameters, Local-Refs? Pattern matching? Nullable-Ref-Types?

This list is open to everyone!

[nikeee]

#14 is also a candidate for this list.

[nikeee]

Most likely, #75 will contain a breaking change. Also, #58 will require some API changes. We also may streamline the method names (Connect -> ConnectAsync) to align with the .NET styles.