JeroenDeDauw added a subscriber: JeroenDeDauw. JeroenDeDauw added a comment.
You are right about there being OCP violations that need fixing. Currently there is this EntityDeserializer, with ItemDeserializer and PropertyDeserializer derivatives. That is very similar to what we had in DataModel with the EntityDiffer code. And I think the solution that should be taken here is the same. Keep having an EntityDeserializer (since people will still want to be able to deserialize entities that are not all of a known same type), but have it delegate to specific deserializers per entity type (ie ItemDeserializer and PropertyDeserializer). This way you avoid the OCP violations and get rid of the code reuse by inheritance. You can try going with the "instanceof StatementListProvider" approach, though I think it's problematic for serialization and not possible for deserialization. For serialization, the addition of a new entity type that does not have a Fingerprint is not going to break anything. Likewise, if it has a new type of attribute, nothing will break (in this code). Instead, you'll just end up getting a partial serialization of the entity, with no warning or hint about that. TASK DETAIL https://phabricator.wikimedia.org/T97706 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene, JeroenDeDauw Cc: JeroenDeDauw, Bene, Aklapper, Wikidata-bugs, aude _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
