Req #55331 [Opn->Dup]: Package/Namespace visibility control keyword

From: Date: Sat, 05 May 2018 21:15:39 +0000
Subject: Req #55331 [Opn->Dup]: Package/Namespace visibility control keyword
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-215100@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=55331&edit=1 ID: 55331 Updated by: requinix@php.net Reported by: gordon dot mcvey at ntlworld dot com Summary: Package/Namespace visibility control keyword -Status: Open +Status: Duplicate Type: Feature/Change Request Package: Class/Object related Operating System: any PHP Version: 5.4.0alpha2 Block user comment: N Private report: N New Comment: Duplicate of request #52297 Previous Comments: ------------------------------------------------------------------------ [2015-08-11 09:34:12] tom at r dot je I was about to post this exact request. This is currently handled by annotations and flagging the method as @api or @internal (see http://phpdoc.org/docs/latest/references/phpdoc/tags/api.html and http://phpdoc.org/docs/latest/references/phpdoc/tags/internal.html ) which are used to denote whether third parties should call the methods or not. The reason for this is simple: It allows package authors to break BC on the methods (or remove them entirely) safe in the knowledge that it won't break third party code because the only place their being called from is the same project. In Java this is handled by the 'protected' keyword which allows any method in the same package to call a method flagged as 'protected'. I'd also like to see a 'package' (or 'namespace', or another word) visibility that mimics this functionality. To make it sensible and actually useful it should be anything in the same root namespace. Example code: x.php <?php namespace Foo\Bar; class X { package function y() { } } ?> y.php <?php namespace Foo\Whatever; class Y { public function __construct() { $x = new \Foo\Bar\X; $x->y(); //ALLOWED } } ?> z.php <?php namespace Another\Project\Entirely; class Y { public function __construct() { $x = new \Foo\Bar\X; $x->y(); //NOT ALLOWED } } ?> ------------------------------------------------------------------------ [2014-05-08 21:26:33] i_am_vib at yahoo dot com Any news regarding this feature? ------------------------------------------------------------------------ [2013-04-05 20:22:57] edp at ultradrive dot com As in Java, the package access level should be implemented both for entire classes and for individual members in a class. ------------------------------------------------------------------------ [2012-04-05 09:57:06] info at strictcoding dot co dot uk This would be awesome. It's currently very difficult to protect a domain model without this feature. ------------------------------------------------------------------------ [2011-07-31 21:42:33] gordon dot mcvey at ntlworld dot com Description: ------------ With the addition of namespaces, a new level of member protection for classes similar to Java's package visibility would be a useful addition. Currently we have the following protection levels: * Private: Member is visible only within the class that defines it * Protected: Member is visible within the class that defines it and any subclasses that inherit from it * Public: Member is visible anywhere. I would suggest that an additional "package" or "namespace" protection level keyword would be a useful addition. Members marked as package or namespace would be visible to any other class defined in the same namespace as the defining class. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=55331&edit=1

« previous php.bugs (#215100) next »