Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66271
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mrclay.org from 50.22.11.19 cause and error)
Message-ID: <512E2161.8060000@mrclay.org>
Date: Wed, 27 Feb 2013 10:08:17 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <AB950117-17A2-4729-8CB0-0C5CACE0B20C@me.com> <op.ws5n08ogc9evq2@nikita2206-n56vj>
In-Reply-To: <op.ws5n08ogc9evq2@nikita2206-n56vj>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] I would like to write an RFC for the addition of an
 internal keyword
From: steve@mrclay.org (Steve Clay)

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/