Open mhrimaz opened 8 months ago
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.
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
andAnnotatedRelationshipElement
are a special case and I guess an instance ofAnnotatedRelationshipElement
should never be considered equal to an instance ofRelationshipElement
. Reasoning is, that if you follow through with this logic you should also consider an emptyProperty
equal to an emptyRange
element because both are instances ofSubmodelElement
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.
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).
I created a separate issue for the PR #248 and allowing mixed-type equals which also mentioned in the community meeting: https://www.eclipse.org/lists/aas4j-dev/msg00041.html
Metamodel elements defined as interfaces (like
public interface Property extends DataElement
) and aas4j allows to have various concrete implementation. The most important advantage is to allow someone to have a more efficient implementation (use linked list instead of array list, or keep some internal states for more efficient navigations,...). However, if we have different implementation of an entity (e.g.Property
), should we allowed to compare them?The mentioned article shed lights on many logical challenges: http://www.angelikalanger.com/Articles/JavaSolutions/SecretsOfEquals/Equals-2.html
As mentioned in the article not allowing mixed-type makes life easier. But we can also see other examples that allow it. As an example the
equals
for javaArrayList
allows any subtype of List for comparison. So you can compare LinkedList with ArrayList.So the most important thing is to define a clear logic and semantic as it might get very tricky.
For example we have
AnnotatedRelationshipElement
andRelationshipElement
. Shouldequals
be always false? or ifAnnotatedRelationshipElement
has no annotation, then it can be comparable toRelationshipElement
.