Fix documentation for Revision::getComment and WikiPage::getComment
authorThiemo Kreuz <thiemo.kreuz@wikimedia.de>
Tue, 15 Jan 2019 13:30:45 +0000 (14:30 +0100)
committerThiemo Kreuz <thiemo.kreuz@wikimedia.de>
Tue, 15 Jan 2019 13:42:17 +0000 (14:42 +0100)
commit631be0b64d071f894f9819d23bb45170f33e6fc0
tree7a3b548ccbd39a7df6f34118c9eb63c930a5c232
parentca8678e23815a6fe8e71e897b4654cbd17a4447d
Fix documentation for Revision::getComment and WikiPage::getComment

This mismatch between the documentation and how the code behaves was
introduced via Ia4c20a9 in December 2017. The getComment() methods have
never been documented to return null, but now do.

I tried to fix this both ways (see I32202df for the other approach), but
decided it's easier and cleaner to keep the null. Reasoning:

* The code behaves like this for more than a year already. Removing the
  null would possibly be as desruptive as when it was introduced.

* Removing the null breaks Wikibase.

* I think returning null is the right thing to do.

I did a brief check of all callers of these two methods. I found a few
that might misbehave a little bit when they are confronted with null, e.g.
in MobileFrontend or Echo. In the vast majority of cases the null will be
silently casted to an empty string and be fine. In a few cases a "the
comment is empty" message might disappear, and the null be shown in the UI
instead, possibly resulting in an empty, confusing HTML element. I would
argue this is an issue with the frontend code then. It should not expect
to have access to all comments. Some might be supressed.

Bug: T174025
Change-Id: I0e1ff9686d1d875812460631c29330c398e74bcf
includes/Revision.php
includes/page/WikiPage.php