Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66275
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <512E2161.8060000@mrclay.org>
References: <AB950117-17A2-4729-8CB0-0C5CACE0B20C@me.com> <op.ws5n08ogc9evq2@nikita2206-n56vj>
 <512E2161.8060000@mrclay.org>
Date: Wed, 27 Feb 2013 16:22:35 +0100
Message-ID: <CALtuQzB6LfgX+CsrcyZhv=C-nd_yh3fuHgj0a1+sDenNYD8T8Q@mail.gmail.com>
To: Steve Clay <steve@mrclay.org>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044286ce37f57d04d6b6599d
Subject: Re: [PHP-DEV] I would like to write an RFC for the addition of an
 internal keyword
From: krebs.seb@gmail.com (Sebastian Krebs)

--f46d044286ce37f57d04d6b6599d
Content-Type: text/plain; charset=ISO-8859-1

2013/2/27 Steve Clay <steve@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

--f46d044286ce37f57d04d6b6599d--