daniel added a comment.

@Bene: the classes in the core model would get a method to get a different 
"role" or "facet". That doesn't add much to the data model. If we use the 
"alternative implementation" I outlined, this doesn't even add any overhead in 
terms of allocated objects.

The easiest way to get role support to all data model objects is a base class. 
Not the nicest approach in terms of abstraction, but avoids overhead and 
redundant code. And since the methods defined in the base class are part of the 
public interface, not internal helpers, it should be ok. I also don't see any 
point in having alternative implementations of Statement or SiteLink, 
especially if we have support for attaching arbitrary roles.

Anyway, it's  always possible to just look at the "main" part of the model, or 
only at specific roles. This is one of the nice things about the ROP: all the 
roles are completely independent, and code that deals with one doesn't have to 
know anything about the others (or even about the core model). Classes 
implementing individual roles don't have to know anything about the data model, 
any object can be used as a role.

-----

PS: We could go one step further by implementing a static utility function that 
does a "role cast". It could be used with any object; if the object didn't 
implement any support for roles, the utility would behave as if the object did 
support roles, but not the particular role you asked for. This would allow the 
core model to no even mention roles. in the interface. Implementations may or 
may not support roles. Calling code would just use Role::case( $obj, $role, 
$type ) to get a different "angle" on an object.

But that may be going a step to far, making this too generic.


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

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

To: daniel
Cc: Bene, Lydia_Pintscher, mkroetzsch, adrianheine, hoo, thiemowmde, aude, 
Jonas, JanZerebecki, JeroenDeDauw, Aklapper, StudiesWorld, daniel, 
Wikidata-bugs, Mbch331



_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to