Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51639
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 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
         :content-type;
        b=ljoWmpdnHZFhuBZ2RNlQFvCamGNh8NtMkhsw8fWAXtLR4jdwHOm+hkIIjQNKwT7VZ4
         wHoT3H9nMChbKiNv5fdFdP3cgBcsuiOXCiufxrG7CpJJFiXiR45iS1UiQSOa454Up83Z
         3hg3zk/pfEgxfMAsXsz+qqm86jwjoFlPmKjkE=
MIME-Version: 1.0
In-Reply-To: <8423995CEEEA844CB2F964B14BCA94CD043ABC80@PRODEXCHANGE02.ilchildcare.org>
References: <8423995CEEEA844CB2F964B14BCA94CD043ABC80@PRODEXCHANGE02.ilchildcare.org>
Date: Wed, 9 Mar 2011 16:11:07 +0100
Message-ID: <AANLkTimN6Ws6zM-Egq=eFFeemRN3hOeW9jUih0zg86jg@mail.gmail.com>
To: Jarrod Nettles <JNettles@inccrra.org>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf303bfffc681321049e0e234c
Subject: Re: [PHP-DEV] Class Access Modifiers
From: landeholm@gmail.com (Hannes Landeholm)

--20cf303bfffc681321049e0e234c
Content-Type: text/plain; charset=ISO-8859-1

Good Sugesstion.

Currently I'm forced to use huge internal classes for my framework because
dividing them into smaller classes would expose internal behavior to the
"outside"... the application layer.

This would solve that problem.

~Hannes


On 3 March 2011 18:21, 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
>

--20cf303bfffc681321049e0e234c--