Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66384
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain me.com designates 17.158.232.236 as permitted sender)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Message-ID: <EE21CA7D-77C6-4535-90A1-AD3025655F9B@me.com>
Date: Fri, 01 Mar 2013 07:23:04 +0100
To: steve@mrclay.org, "internals@lists.php.net" <internals@lists.php.net>
MIME-version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [PHP-DEV] I would like to write an RFC for the addition of an
 internal keyword
From: ibmurai@me.com (Jens Riisom Schultz)


> Setting aside difficulty of implementation, I'm coming around to the =
idea, though I think you could simplify it by cordoning off an entire =
namespace. E.g.:
>=20
> A namespace at least two deep (e.g. \A\B\) may be marked 'protected' =
(by some method TBD). Classes and functions declared in a protected =
namespace can only be accessed from methods or functions inside the same =
namespace, or in ancestor namespaces.
>=20
> E.g., if \Foo\Internal\ is protected, access of its classes/functions =
must originate from classes/functions defined in \Foo\, \Foo\Internal\, =
or \Foo\Internal\*.
>=20
> This would allow something like nested classes, but obviously with a =
lot more flexibility.
>=20
> In practice, plugin code sitting in, say, \MyPlugin\ could freely =
access \Framework\SomeClass, but not \Framework\Internal\SomeClass.

This would solve the problem of internal classes, but these are the =
least interesting part, imho - The methods and properties are much more =
interesting, hence my new approach in response to Fabians response, =
where I drop the concept of internal classes. Please refer to that.

>=20
> I see some value there, but there's tons of questions remaining and =
how to to implement the damn thing...
>=20
> Steve Clay

-Jens=