Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51628
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain inccrra.org designates 216.201.124.135 as permitted sender)
To: 'Martin Scotta' <martinscotta@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Class Access Modifiers
Thread-Index: AQHL2c4iTYnlF4SLTESDPkZOxcMXh5Qj+3dQ
Date: Tue, 8 Mar 2011 21:27:48 +0000
Message-ID: <8423995CEEEA844CB2F964B14BCA94CD043AC2A1@PRODEXCHANGE02.ilchildcare.org>
References: <8423995CEEEA844CB2F964B14BCA94CD043ABC80@PRODEXCHANGE02.ilchildcare.org>
 <AANLkTikcn2_v2+G=tECUgqD6iOjM+6dCmdq96t5bxCUm@mail.gmail.com>
In-Reply-To: <AANLkTikcn2_v2+G=tECUgqD6iOjM+6dCmdq96t5bxCUm@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_8423995CEEEA844CB2F964B14BCA94CD043AC2A1PRODEXCHANGE02i_"
MIME-Version: 1.0
Subject: RE: [PHP-DEV] Class Access Modifiers
From: JNettles@inccrra.org (Jarrod Nettles)

--_000_8423995CEEEA844CB2F964B14BCA94CD043AC2A1PRODEXCHANGE02i_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Either that or it should be spun off into its own RFC. I have no idea how t=
o do either.

From: Martin Scotta [mailto:martinscotta@gmail.com]
Sent: Thursday, March 03, 2011 12:09 PM
To: Jarrod Nettles
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Class Access Modifiers

I'm writing a RFC about improvements on the current OO Model.

do you want to add this?

http://wiki.php.net/rfc/object-model-improvements

 Martin Scotta

On Thu, Mar 3, 2011 at 2:21 PM, Jarrod Nettles <JNettles@inccrra.org<mailto=
:JNettles@inccrra.org>> wrote:
Has there been any discussion on access modifiers for classes? I looked thr=
ough the existing RFCs and searched through old discussions on the mailing =
list but didn't come up with anything.

Specifically, I think it would be beneficial (for framework developers in p=
articular) if classes could be marked as public, private, etc. I haven't re=
ally thought through exact definitions on how each modifier would restrict =
but here is a use case.

A developer is working on an object-oriented framework that uses namespaces=
 and uses classes extensively. He considers many of the classes to be for i=
nternal use only, that is, they will only be used by the internal workings =
of the framework core, not by any web application that somebody builds usin=
g his framework. That being the case, the developer would like to restrict =
access to certain classes so  that they can only be accessed in certain sit=
uations.

Proposal (after five minutes of thought)


1.       Public - A class can be instantiated or called statically from any=
where. For reasons of backward compatibility a class without any modifier w=
ould be considered public.

2.       Internal - A class can only be instantiated/called from within the=
 same root namespace. If I have a class Core\Mvc\View, only from within a c=
lass sharing the same root namespace (ex: Core\Html\Textbox) would I be abl=
e to access the "View" class.

3.       Private - A class can only be instantiated/called from within the =
exact same namespace. Example, class Core\Mvc\View could only be accessed f=
rom a class in the Core\Mvc namespace (ex: Core\Mvc\Controller).

What do people think? I'm not too concerned with the exact three I listed a=
bove, but more and more I think it would be wise if there were a way to res=
trict the accessibility of classes between namespaces.

Jarrod Nettles
Application Developer - Technology
INCCRRA
p 309.829.5327 - f 309.828.1808

This e-mail message may contain privileged or confidential information. If =
you are not the intended recipient, you may not disclose, use, disseminate,=
 distribute, copy or rely upon this message or attachment in any way. If yo=
u received this e-mail message in error, please return by forwarding the me=
ssage and its attachments to the sender. INCCRRA does not accept liability =
for any errors, omissions, corruption or virus in the contents of this mess=
age or any attachments that arises as a result of e-mail transmission.

Please consider your environmental responsibility before printing this e-ma=
il


Jarrod Nettles
Application Developer - Technology
INCCRRA
p 309.829.5327 - f 309.828.1808

This e-mail message may contain privileged or confidential information. If =
you are not the intended recipient, you may not disclose, use, disseminate,=
 distribute, copy or rely upon this message or attachment in any way. If yo=
u received this e-mail message in error, please return by forwarding the me=
ssage and its attachments to the sender. INCCRRA does not accept liability =
for any errors, omissions, corruption or virus in the contents of this mess=
age or any attachments that arises as a result of e-mail transmission.

Please consider your environmental responsibility before printing this e-ma=
il

--_000_8423995CEEEA844CB2F964B14BCA94CD043AC2A1PRODEXCHANGE02i_--