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

Consider provided immutable classes for generic fields #104

Open
danielFesenmeyer opened this issue Nov 20, 2017 · 2 comments
Open

Consider provided immutable classes for generic fields #104

danielFesenmeyer opened this issue Nov 20, 2017 · 2 comments

Comments

@danielFesenmeyer
Copy link

When I have declared some class as immutable, I would expect that a class having a field of a generic subtype of this class is also considered as immutable.

But this does not work. The following test fails:

    @Test
    public void assertImmutability() {
        assertInstancesOf(ClassWithGenericField.class, areImmutable(),
                provided(SomeInterface.class).isAlsoImmutable());
    }


    private static final class ClassWithGenericField<T extends SomeInterface> {
        private final T field;

        public ClassWithGenericField(final T field) {this.field = field;}

        public T getField() {
            return field;
        }
    }

    private interface SomeInterface {

    }
@Grundlefleck
Copy link
Contributor

Yup, I think that's a fair assessment.

I know it's not the same assertion, but this might be a workaround in the meantime:

assertInstancesOf(ClassWithGenericField.class, areImmutable(), provided("T").isAlsoImmutable());

I'm not sure if the generic type information is available to the isAlsoImmutable() matcher, but we definitely capture generic information, so might just be a case of storing it for access later. I'm afraid I've no ETA on this, just due to family+time commitments. How badly is it affecting you?

@danielFesenmeyer
Copy link
Author

Thanks for the workaround :)

This is not urgent for us, it's more a nice-to-have.

l0s added a commit to l0s/MutabilityDetector that referenced this issue Oct 15, 2019
Given a class with a generic type parameter T, where T is guaranted to
be an instance of U. If the class has a final field of type T and U has
been guaranteed to be immutable, then the class will also be considered
immutable.

This implementation modifies the "allowing" matcher only. It uses
reflection to determine if the field type being assigned had previously
been specified immutable.

Addresses: MutabilityDetector#104
Grundlefleck pushed a commit that referenced this issue Oct 17, 2019
Given a class with a generic type parameter T, where T is guaranted to
be an instance of U. If the class has a final field of type T and U has
been guaranteed to be immutable, then the class will also be considered
immutable.

This implementation modifies the "allowing" matcher only. It uses
reflection to determine if the field type being assigned had previously
been specified immutable.

Addresses: #104
l0s added a commit to l0s/MutabilityDetector that referenced this issue Oct 21, 2019
This adds a field in `FieldLocation` to capture its type. Downstream
`MutableReasonDetail` Matchers can leverage that to decide whether or
not a violation is valid.

This is an optimisation to PR MutabilityDetector#144 which uses Reflection to accomplish
the same thing.

Addresses: MutabilityDetector#104
l0s added a commit to l0s/MutabilityDetector that referenced this issue Oct 24, 2019
l0s added a commit to l0s/MutabilityDetector that referenced this issue Oct 24, 2019
This adds null checks to the `FieldLocation` constructor and fixes the
scenarios in which null was being provided.

Addresses: MutabilityDetector#104
Grundlefleck pushed a commit that referenced this issue Oct 27, 2019
This adds a field in `FieldLocation` to capture its type. Downstream
`MutableReasonDetail` Matchers can leverage that to decide whether or
not a violation is valid.

This is an optimisation to PR #144 which uses Reflection to accomplish
the same thing.

Addresses: #104
Grundlefleck pushed a commit that referenced this issue Oct 27, 2019
This addresses code review feedback in #145.

Addresses: #104
Grundlefleck pushed a commit that referenced this issue Oct 27, 2019
This adds null checks to the `FieldLocation` constructor and fixes the
scenarios in which null was being provided.

Addresses: #104
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants