Page MenuHomePhabricator

All API members should be protected or public and no const
Closed, DeclinedPublic

Description

Author: wilson.jim.r

Description:
Please make all members of all classes in the API either protected or public (not private), and remove all "const" declarations.

Examples:

  • mModules in ApiMain.php - since it's private, changing any of the factory targets requires duplicating the entire class
  • LIMIT_BIG1 and LIMIT_BIG2 in ApiBase.php - Extending classes should have the option of setting their own limits

Reasoning:

Keeping anything private means that to change it requires duplicating the entire class, or in some cases an entire class hierarchy. This encourages code duplication and hinders development by raising the level of work required both in development and maintenance.

I can provide more examples if necessary - this is a sweeping change.


Version: unspecified
Severity: normal

Details

Reference
bz10602

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:52 PM
bzimport set Reference to bz10602.
bzimport added a subscriber: Unknown Object (MLST).

cannon.danielc wrote:

(In reply to comment #0)

Please make all members of all classes in the API either protected or public
(not private), and remove all "const" declarations.

I'm changing this to WONTFIX. Private members in the API are private for a reason--to ensure for their correct usage. If there's a need to read a certain value, we can provide a getter -- if there's a need to write a certain value, we can provide a specialized setter. In general, all members should allow the least access possible--preferably private--with accessors as necessary.

In the specific case of mModules, which you mention, the field is private--quite simply--because you should not be accessing the modules directly or instatiating the classes they specify; rather, all class instantiation should be done through ApiMain. The prospect of allowing external classes to *write* to mModules is a frightening one indeed, and one that will lead you only to enormous headaches and broken (or incredibly fragile) code.

If there any particular accessors that you need for internal invocation, please do let us know. Discussion of expanding internal access is ongoing at http://www.mediawiki.org/wiki/API:Calling_internally.