Drop RespectingRuntimeTypes and RespectingDeclaredTypes

I propose to drop those two methods for a couple of reasons:

They confuse a lot of people
Only affect the expectation and not the subject
They only affect the top-level members of an object. As soon as BeEquivalentTo goes one level deeper, it will fall-back to the run-time types.

If somebody really wants to include or exclude certain members, they can either use an anonymous type as the expectation or use one of the other APIs to include or exclude certain members.

Also may affect #1860

I really like that we revise if the default of only looking at the declared types is still the right choice 👍

I tried removing RespectingRuntimeTypes and RespectingDeclaredTypes and surprisingly only 11 tests failed.

AssertionRuleSpecs
- When_the_compile_time_type_does_not_match_the_equality_comparer_type_it_should_use_the_default_mechanics
CollectionSpecs
- When_an_object_implements_multiple_IEnumerable_interfaces_but_the_declared_type_is_assignable_to_only_one_it_should_respect_the_declared_type
- When_the_expectation_is_an_array_of_interface_type_it_should_respect_declared_types
NestedPropertiesSpecs
- When_not_all_the_properties_of_the_nested_objects_are_equal_it_should_throw
SelectionRulesSpecs
- Excluding_a_covariant_property_through_the_base_class_excludes_the_base_class_property
- Includes_hidden_field_of_the_base_when_using_a_reference_to_the_base
- Includes_hidden_property_of_the_base_when_using_a_reference_to_the_base
- When_respecting_declared_types_explicit_interface_member_on_interfaced_subject_should_be_used
- When_respecting_declared_types_explicit_interface_member_on_interfaced_expectation_should_be_used
- When_a_reference_to_an_interface_is_provided_it_should_only_include_those_properties
- When_a_reference_to_an_explicit_interface_impl_is_provided_it_should_only_include_those_properties

If somebody really wants to include or exclude certain members, they can either use an anonymous type as the expectation or use one of the other APIs to include or exclude certain members.

We should remind ourselves that the expectation might not be a static value, but could also be a computed one.

For When_an_object_implements_multiple_IEnumerable_interfaces_but_the_declared_type_is_assignable_to_only_one_it_should_resp
I don't know how to disambiguate which IEnumerable<> to use.

If we discover properties based on the runtime type, which of the two Name properties should we favor?

class Person : IPerson
{
    public string Name { get; set; }
    
    string IPerson.Name { get; set; }
}

If we discover properties based on the runtime type, which of the two Name properties should we favor?

In #2152, I've chosen to prefer the normal property over the explicitly implemented one.

We should remind ourselves that the expectation might not be a static value, but could also be a computed one.

We still support various overloads of Excluding that you can use to exclude certain members from the expectation. Or do I misunderstand your point?

I tried removing RespectingRuntimeTypes and RespectingDeclaredTypes and surprisingly only 11 tests failed.

When_respecting_runtime_types_explicit_interface_member_on_interfaced_subject_should_not_be_used would also be affected by removing the options.

If we discover properties based on the runtime type, which of the two Name properties should we favor?

In #2152, I've chosen to prefer the normal property over the explicitly implemented one.

👍 I wrote this before my latest review on #2152

We should remind ourselves that the expectation might not be a static value, but could also be a computed one.

We still support various overloads of Excluding that you can use to exclude certain members from the expectation. Or do I misunderstand your point?

I had forgotten we have Exclude for collection members.

@jnyrup

@jnyrup do you agree if I remove them altogether?

I agree.

grepp.app has zero(!) uses of RespectingDeclaredTypes outside of this repo.
Google has very few results for RespectingDeclaredTypes

On second thought, while trying to remove them in this PR, I concluded we should keep them. The default FA uses is to internally call RespectingDeclaredTypes. People can override that behavior using RespectingRuntimeTypes (or by calling IncludingAllRuntimeProperties) and that one I see more often when searching the internet like you did.

Instead, I'm now suggesting to rename those two methods to better describe what they do

RespectingRuntimeTypes to PreferRuntimeMemberTypes
RespectingDeclaredTypes to PreferCompileTimeMemberTypes

Almost all methods in SelfReferenceEquivalencyOptions use the passive -ing form.

Not sure what CompileTime vs Runtime means in this context.

PreferringRuntimeMemberTypes and PreferringDeclaredMemberTypes?

Yeah, let's go with that.

Navigation Menu

Repository navigation

Drop RespectingRuntimeTypes and RespectingDeclaredTypes #2252

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Drop RespectingRuntimeTypes and RespectingDeclaredTypes #2252

Description

Activity

jnyrup commented on Sep 23, 2023

dennisdoomen commented on Sep 23, 2023

jnyrup commented on Sep 23, 2023

dennisdoomen commented on Nov 29, 2024

jnyrup commented on Nov 29, 2024

dennisdoomen commented on Dec 1, 2024

jnyrup commented on Dec 4, 2024

dennisdoomen commented on Dec 4, 2024

jnyrup commented on Dec 4, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions