Just following up on some discussion I had with DanielK and Jeroen today on
this, and summarizing it for the mailing list.
I still fail to see what the advantage would be to use the IRI datavalue -
especially when it is basically stripped down to be a string datavalue, as
Jeroen suggests in the
Hey,
The naming questions for two of the new components have not been resolved
yet.
DataValues interfaces (still need a good name for this), will hold
interfaces, exceptions and trivial implementations of ValueParsers,
ValueFormatters and ValueValidators. Depends on DataValues
I'm going with
Hi!
I'm getting closer and closer to writing UI for badges in repo. Does anyone
have any ideas?
The only thing I came with is a additional row beneath each site link which
behaves (and looks) like aliases editing currently does, but I think that this
would take too much space.
Thanks,
Michał
Hey,
The reorganization into new components has been completed in the
DataValues.git repo itself.
https://gerrit.wikimedia.org/r/#/c/81966/
There are a few classes that might still move from one to the other,
pending discussion. Those will be local changes not affecting the overall
picture much
Hey,
Fun fact, after the EntityId refactoring, Entity is now the highest risk
class in the component according to PHPUnit.
- Entity (200)
- HashArray (71)
- Item (45)
- EntityDiff (41)
- Claims (27)
- ObjectComparer (23)
- EntityId (22)
- SnakObject (21)
- Claim (19)
Hey,
I got asked what high risk in my last email means.
These results are using the CRAP metric [0] to determine the CRAPiness of
the code (which is indicated by the number in brackets). You can have
PHPUnit generate this by running the following command in the root
directory of
