Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51646
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: 'Hannes Landeholm' <landeholm@gmail.com>, "internals@lists.php.net"
	<internals@lists.php.net>, "'james.butler@edigitalresearch.com'"
	<james.butler@edigitalresearch.com>
Thread-Topic: [PHP-DEV] Class Access Modifiers
Thread-Index: AQHL3mw6xnNHrJES802i5qxns5t+OZQlRSZQ
Date: Wed, 9 Mar 2011 18:02:36 +0000
Message-ID: <8423995CEEEA844CB2F964B14BCA94CD043AC586@PRODEXCHANGE02.ilchildcare.org>
References: <8423995CEEEA844CB2F964B14BCA94CD043ABC80@PRODEXCHANGE02.ilchildcare.org>
 <AANLkTimN6Ws6zM-Egq=eFFeemRN3hOeW9jUih0zg86jg@mail.gmail.com>
In-Reply-To: <AANLkTimN6Ws6zM-Egq=eFFeemRN3hOeW9jUih0zg86jg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_8423995CEEEA844CB2F964B14BCA94CD043AC586PRODEXCHANGE02i_"
MIME-Version: 1.0
Subject: RE: [PHP-DEV] Class Access Modifiers
From: JNettles@inccrra.org (Jarrod Nettles)

--_000_8423995CEEEA844CB2F964B14BCA94CD043AC586PRODEXCHANGE02i_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Interesting question. My gut tells me not (as does three years of C# experi=
ence). I=92m sure that everyone will have a different opinion on this but t=
o me it seems taboo that a child class override the visibility of the paren=
t class. For example, PHP currently does not allow you to override a method=
 with a lower or higher visibility than the parent =96 I can=92t go from pr=
otected to public or vice versa. Visibility must be maintained throughout t=
he class hierarchy.

I realize that ten thousand people will curse up and down the first time th=
ey try  to extend an internal class with a public one but good application =
design should be the real solution.


>> Proposal (after five minutes of thought)
>>
>>
>> 1.       Public - A class can be instantiated or called statically from
>> anywhere. For reasons of backward compatibility a class without any modi=
fier
>> would 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
>> class sharing the same root namespace (ex: Core\Html\Textbox) would I be
>> able to access the "View" class.
>>
>> 3.       Private - A class can only be instantiated/called from within t=
he
>> exact same namespace. Example, class Core\Mvc\View could only be accesse=
d
>> from 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 liste=
d
>> above, but more and more I think it would be wise if there were a way to
>> restrict the accessibility of classes between namespaces.
>>
>> Jarrod Nettles
>>
Really like the general idea and think (IMHO) its RFC worthy, but have a
few questions...
Would there be any method of overriding the the visibility in a child
class?And would the child class inherit the parents visibility?
I realise this may seem daft initially but I can think of some instances
where this might be useful.

James

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_8423995CEEEA844CB2F964B14BCA94CD043AC586PRODEXCHANGE02i_--