Last modified: 2011-03-13 18:06:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T12602, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10602 - All API members should be protected or public and no const
All API members should be protected or public and no const
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-16 15:43 UTC by Jim R. Wilson
Modified: 2011-03-13 18:06 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jim R. Wilson 2007-07-16 15:43:37 UTC
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.
Comment 1 Daniel Cannon (AmiDaniel) 2007-07-17 06:25:18 UTC
(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>.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links