Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow IsOfType to accept subclasses of the specified type #86

Closed
mysticfall opened this issue Jan 13, 2018 · 5 comments · Fixed by #143
Closed

Allow IsOfType to accept subclasses of the specified type #86

mysticfall opened this issue Jan 13, 2018 · 5 comments · Fixed by #143
Labels

Comments

@mysticfall
Copy link

Currently, IsOfType throws an exception when type of the passed object is different from the specified type.

However, it is often desired to see if an object is a subclass of a certain type. So, it could be useful if we can make IsOfType optionally accept any subclass of the specified type rather than an instance that exactly matches it.

@danielwertheim
Copy link
Owner

danielwertheim commented Feb 1, 2018

@mysticfall To not break existing functionality, would it work if a new method was introduced, e.g IfAnyTypeOf ?

@mysticfall
Copy link
Author

Sure, it sounds like a reasonable thing to do, preserving compatibility for existing users to me.

ndrwrbgs added a commit to ndrwrbgs/Ensure.That that referenced this issue Nov 4, 2018
ndrwrbgs added a commit to ndrwrbgs/Ensure.That that referenced this issue Nov 4, 2018
@ndrwrbgs
Copy link
Contributor

ndrwrbgs commented Dec 8, 2019

I've implemented this in https://www.nuget.org/packages/Ensure.That.Experimental/0.1.0 since this Ensure.That library provides a really nice extendable API (at least for the Ensure.That and Ensure.{Type} syntaxes).

I'd like to move that under @danielwertheim's account or into this library, as applicable, but keeping it separate meant I didn't have to try to match existing style/patterns (okay let's be honest, I mean I didn't write tests yet)

@danielwertheim
Copy link
Owner

I'll gladly accept any PR that is up-to date and that follows the API (so that not yet another flavor is added, unless a good case could be provided for why) and has some (at least one) test.

@loedeman
Copy link
Contributor

loedeman commented Jun 4, 2020

@danielwertheim Just did that - I hope this issue can be solved soon :).

danielwertheim pushed a commit that referenced this issue Jun 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
4 participants