Make type comparisons clearer #80
Assignees
Labels
breaking-change
This will impact or improve our compatibility posture
Comments
paddycarver
added
the
breaking-change
bflad
added a commit
that referenced
this issue
Aug 10, 2021
Reference: #80 Each type now implements three separate and distinct comparison methods: * `(T).Equal()`: performs deep type equality checks, including attribute/element types and whether attributes are optional or not. * `(T).Is()`: performs shallow type equality checks, in that the root type is compared, but underlying attribute/element types are not. * `(T).UsableAs()`: performs type conformance checks. This primarily checks if the target implements `DynamicPsuedoType` in a compatible manner.
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We currently have a very overloaded
Ismethod on types that's used for shallow and deep comparisons. With #79 raising the need for deep comparisons that allow concrete types to be substituted for DynamicPseudoTypes, it has become obvious we need a clearer interface for this.I'm proposing:
Type.Is(Type)is a shallow check, that root types are the same typeType.Equals(Type)is a deep check, that root types and all elements and attributes are the same typeType.ConformsTo(Type)is a deep check, that root types and all elements and attributes conform (are equivalent, or a concrete type is being substituted forDynamicPseudoType)This would lead to less confusion and fewer gotchas around
Type.Is(Type), I believe, and more clarity about what code is actually doing.The text was updated successfully, but these errors were encountered: