vraudszus
commented
2 years ago The issue is that TypeRelation behaves fundamentally different from all other types of relations in this aspect. The allowable ActualObjectType of the subject can only be determined by looking at the object the TypeRelation relates to. And the TypeRelation has a dynamic set of allowable object types and retrieving this set would require access to the ConceptManager. So my idea of having fixed sets of allowable types does not hold up for the TypeRelation.
That is why triplets with the TypeRelation as their predicate are handled by a completely different method in the VariableManager. And unlike the standard method, this method does not rely on the getRelatableSubjectTypes and getRelatableObjectTypes methods.
And to make this difference clear, I decided to override those methods in TypeRelation so that it would not lead to undefined behavior when the methods are accidentally called. If not overwritten the methods would simply return the empty placeholder sets the TypeRelation has for its relatable types, which in my opinion would be worse than having the exception throwing methods around.
@VincentRaudszus The two methods: getRelatableSubjectTypes() and getRelatableObjectTypes() in TypeRelation that literally only throw exceptions when you call them, seem wrong to me. TypeRelation shouldn't inherit these methods if these methods are not allowed to be called. I assume that fixing the Relation hierarchy to remedy this would be alot of work? If that is the case and if those methods are never called anyway (since they would throw exceptions) then I probably would accept this pull request despite my misgivings.