Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51563
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=f5KuvauqIbzQIEdok5sB+H3l4oWQpLH0Gx/yZJzVupcXzFYjM6XrMH+a92gfDjrBK7
         xnnyCbesThyjh1g53KleOZbPxbXaYKXpDEBAdwGepwVyh2PMCFfV0FhoDEIplJv+2ix3
         +Bmhjx2fauX9i7E+iBrvWKFgoXmWVXDBY/nV4=
MIME-Version: 1.0
In-Reply-To: <8423995CEEEA844CB2F964B14BCA94CD043ABC80@PRODEXCHANGE02.ilchildcare.org>
References: <8423995CEEEA844CB2F964B14BCA94CD043ABC80@PRODEXCHANGE02.ilchildcare.org>
Date: Thu, 3 Mar 2011 15:09:21 -0300
Message-ID: <AANLkTikcn2_v2+G=tECUgqD6iOjM+6dCmdq96t5bxCUm@mail.gmail.com>
To: Jarrod Nettles <JNettles@inccrra.org>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec53f8fc7be4724049d97eda6
Subject: Re: [PHP-DEV] Class Access Modifiers
From: martinscotta@gmail.com (Martin Scotta)

--bcaec53f8fc7be4724049d97eda6
Content-Type: text/plain; charset=ISO-8859-1

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> wrote:

> Has there been any discussion on access modifiers for classes? I looked
> through 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
> particular) if classes could be marked as public, private, etc. I haven't
> really 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
> internal 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 using
> 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
> situations.
>
> 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 modifier
> 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 the
> exact same namespace. Example, class Core\Mvc\View could only be accessed
> 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 listed
> 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
> 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 you
> received this e-mail message in error, please return by forwarding the
> message and its attachments to the sender. INCCRRA does not accept liability
> for any errors, omissions, corruption or virus in the contents of this
> message or any attachments that arises as a result of e-mail transmission.
>
> Please consider your environmental responsibility before printing this
> e-mail
>

--bcaec53f8fc7be4724049d97eda6--