On 2/27/13 3:18 AM, Nikita Nefedov wrote:
I, for one, think it should be solved on the IDE side. I used a lot of Doctrine's internal methods lately and if they would be not accessible I wouldn't be able to do a lot of things. Of course internal methods/classes shouldn't be exposed as a part of API, but if they exist, I would want to call them *if I know what I'm doing*. I think it would be useful if phpdoc had an @internal tag so that IDEs could highlight places where you use internal parts of library.
Agreed, IDE/phpDoc is the place for a solution (and I do recognize that there is some need here).
phpDoc already supports "@access private" for items to be left out of public documentation. An IDE could be configured to have these items appear greyed or not to appear in autocomplete lists.
There's already a way to tightly control access: embrace OOP and eliminate statically accessible APIs (global vars/funcs and static props/methods) that you don't want people calling. You don't actually need them. Although closures helped too, PHP gained true information hiding in 5.0 with "private".
Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
