2013/2/27 Steve Clay <st...@mrclay.org> > 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. >
a) You misuse the "private visibility" here: "@access private" comes from old PHP4-days, where the DocComment must know the visibility, because the method itself didn't b) Most doc-tools are able to generate developer-docs, which usually contain all protected and private elements. This "hidden element" will appear as regular private method there. Can be confusing I think :) > > 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". I agree > > > Steve Clay > -- > http://www.mrclay.org/ > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- github.com/KingCrunch
