Allow mixed-type equals about aas4j

[mjacoby]

If we go for mixed-type equality, can we assure that all (future) implementation of an interface like Property will behave in the same expected way or is this up to the developer of each of those classes? If we can't ensure this, might this be a problem?
Does this even require major effort on our site to implement/support this as we only provide a single implementation of each interface?
In general I like the idea of allowing mixed-types equality but only if it makes sense and we don't find major downsides (besides complexity).
One potential downside I can think of is that currently the model code, i.e. also the equals methods, are auto-generated by our generator tool and I am not sure if such a complex pattern could also be auto-generated.

RelationshipElement and AnnotatedRelationshipElement are a special case and I guess an instance of AnnotatedRelationshipElement should never be considered equal to an instance of RelationshipElement. Reasoning is, that if you follow through with this logic you should also consider an empty Property equal to an empty Range element because both are instances of SubmodelElement and in this case they would ne differ in attributes.

[mhrimaz]

If we go for mixed-type equality, can we assure that all (future) implementation of an interface like Property will behave in the same expected way or is this up to the developer of each of those classes? If we can't ensure this, might this be a problem? Does this even require major effort on our site to implement/support this as we only provide a single implementation of each interface? In general I like the idea of allowing mixed-types equality but only if it makes sense and we don't find major downsides (besides complexity). One potential downside I can think of is that currently the model code, i.e. also the equals methods, are auto-generated by our generator tool and I am not sure if such a complex pattern could also be auto-generated.

We can't control how people implement their equals, but all we can is to provide examples and sample test cases to guide them through a correct implementation.
I also don't say definitely that we should have such attribute for equals. The motivation was to test if a CustomProperty can be serialized with RDF serializer, but the reconstructed object for now is always DefaultProperty. So I can't compare them using equals method right now.

RelationshipElement and AnnotatedRelationshipElement are a special case and I guess an instance of AnnotatedRelationshipElement should never be considered equal to an instance of RelationshipElement. Reasoning is, that if you follow through with this logic you should also consider an empty Property equal to an empty Range element because both are instances of SubmodelElement and in this case they would ne differ in attributes.

I also think so. In this case, I need to modify also the current PR if we want to have such behaviour.

[mjacoby]

The motivation was to test if a CustomProperty can be serialized with RDF serializer, but the reconstructed object for now is always DefaultProperty. So I can't compare them using equals method right now.

Another possible solution for this problem would be to add a method similar to useImplementation(Class<T> aasInterface, Class>? extends T> implementation) in JsonDeserializer.java#L59 also for RDF.
I think this would be very beneficial. And if you have something like this it would solve your problem related to testing.

However, this would not answer the question if we should change how equals work in AAS4J (or in certain classes at least).