|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #44290 Request for package access control system
Submitted: 2008-02-29 11:06 UTC Modified: 2019-04-29 21:16 UTC
Avg. Score:4.0 ± 1.7
Reproduced:1 of 2 (50.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: mr at segtel dot dk Assigned:
Status: Suspended Package: *General Issues
PHP Version: 6CVS-2008-02-29 (CVS) OS: All
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2008-02-29 11:06 UTC] mr at segtel dot dk
I would like to request a package access control system to accompany public, private and protected as defined by OMG for UML.

Reproduce code:
package my_package {
  class some_class {
    package $var;

  class other_class {
    private $obj;

    public function __construct() {
      $this->obj = new some_class();

    public function do_something() {
      print $this->obj->var;

Expected result:
The above should work. my_package::some_class::var is accessible by other classes inside the my_package package whereas any other class does not have access.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2019-04-29 19:09 UTC] pharaun dot mizzrym dot 86 at gmail dot com
I would love that feature as well. I would have loved namespaces to be implemented that way, but it seems like nowdays those are most commonly used for autoloaders to find the scripts inside a folder structure (psr-4). 

I'd like to have "package" work similar to a namespace though, so it'll work easier across multiple files, but with visibility on classes. 

Example code:

package App\User;
namespace App\User\Some\Namespace;

// not available outside package "App\User"
private class UserRepository {

package App\User;
namespace App\User\Some\Other\Namespace;

use App\User\Some\Namespace\UserRepository;

// available outside package
public class UserFactory {
    private function getUserRepository(): UserRepository {
        return new UserRepository(); // works, because it's in the same package

Expected result:
// no package, no namespace
// or different package
// or just namespace without package

use App\User\Some\Namespace\UserRepository;     // will cause error (private class)
use App\User\Some\Other\Namespace\UserFactory;  // works (public class)

It would allow developers to "hide" classes intended for use inside a part of a program (module, bundle or similar) only and enforce the use of design patterns like factories or facades for where it is deemed necessary. 
It would deny unintended uses of classes and reduce the possibility of unwanted dependencies.

Also, as a minor quality of life improvement, it would allow IDE developers to reduce the amount of possible classes shown after typing "new", which can be quite a lot in big projects, although only a few are actually intended to be used alongside "new", outside the 'package' they come from.
 [2019-04-29 21:16 UTC]
-Status: Open +Status: Suspended -Package: Feature/Change Request +Package: *General Issues
 [2019-04-29 21:16 UTC]
The problem is that PHP then has to check who is trying to access what at runtime. That's expensive.

This request is beyond the scope of what can be handled on this bug tracker. Anyone interested in this idea should check out the RFC process.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Fri Oct 22 14:03:39 2021 UTC