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 <jnett...@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 >
