<story><title>OAuth 3</title><url>https://oauth.net/3/</url></story><parent_chain><item><author>parhamn</author><text>&amp;gt; Polymorphic JSON. The protocol elements have different data types that convey additional contextual meaning, allowing us to avoid mutually exclusive protocol elements and design a more succinct and readable protocol.&lt;p&gt;Yeah... let&amp;#x27;s not please.</text></item></parent_chain><comment><author>samprotas</author><text>The number of comments here specifically upset with this part of the current design is a bit discouraging, but not necessarily surprising.&lt;p&gt;Yes, many mainstream languages have near-zero support for Tagged&amp;#x2F;Discriminated Unions or Enums with Associated Data or Algebraic Data Types (pick your favorite name for the same concept). This is a limitation of those languages, which should not force a language-agnostic protocol to adopt the lowest common denominator of expressiveness.&lt;p&gt;Consider the problem they&amp;#x27;re avoiding of mutually exclusive keys in a struct&amp;#x2F;object. What do you do if you receive more than one? Is that behavior undefined? If it is defined, how sure are you that the implementation your package manager installed for you doesn&amp;#x27;t just pick one key arbitrarily in the name of &amp;quot;developer friendliness&amp;quot; leading to security bugs? This seems like a much more bug-ridden problem to solve than having to write verbose type&amp;#x2F;switching golang&amp;#x2F;java.&lt;p&gt;Implementing more verbose deserialization code in languages with no support for Tagged Unions seems like a small price to pay for making a protocol that leaves no room for undefined behavior.&lt;p&gt;To be clear, _many_ statically typed languages have perfect support for this concept (Rust&amp;#x2F;Swift&amp;#x2F;Scala&amp;#x2F;Haskell, to name a few).</text></comment>
<story><title>OAuth 3</title><url>https://oauth.net/3/</url></story><parent_chain><item><author>parhamn</author><text>&amp;gt; Polymorphic JSON. The protocol elements have different data types that convey additional contextual meaning, allowing us to avoid mutually exclusive protocol elements and design a more succinct and readable protocol.&lt;p&gt;Yeah... let&amp;#x27;s not please.</text></item></parent_chain><comment><author>kevincox</author><text>Yeah, put a `type` tag in there and call it a day.</text></comment>