Lucas_Werkmeister_WMDE added a comment.

Okay, so how about this:

  • Extract Context::storeCheckResultInArray into a separate interface. (I’ll go with ContextCursor for now – I don’t think CompactContext or something like that really fits, because this isn’t just a different representation of a Context, it’s a separate thing.) Use three different implementations for the different context types we have.
  • Add Context::getCursor(), to return the associated ContextCursor.
  • Change CheckResult to hold a ContextCursor instead of a full Context. (We could even make the constructor accept both, and call getCursor if necessary, so that none of the callers would have to change. Might be worth it, at least as an interim measure.)
  • ContextCursor is easily serializable. (However, it’s not completely trivial – deserialization needs to instantiate one of three different classes – so I’d still add dedicated serializer and deserializer classes, instead of just having methods on ContextCursor itself.)
  • We don’t (yet?) offer any way to get from a ContextCursor back to a full Context.
  • Apart from this, Context stays as it is for now (no ContextData).

TASK DETAIL
https://phabricator.wikimedia.org/T185712

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lucas_Werkmeister_WMDE
Cc: Ladsgroup, Aklapper, Lucas_Werkmeister_WMDE, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, Wikidata-bugs, aude, Mbch331
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to