php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #44194 Add private modifiers to namespace classes
Submitted: 2008-02-20 22:20 UTC Modified: 2018-05-05 19:34 UTC
Votes:11
Avg. Score:4.5 ± 0.8
Reproduced:5 of 5 (100.0%)
Same Version:2 (40.0%)
Same OS:3 (60.0%)
From: kalle@php.net Assigned:
Status: Wont fix Package: *General Issues
PHP Version: 5.2CVS-2008-02-20 (CVS) OS: Windows XP
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
39 - 30 = ?
Subscribe to this entry?

 
 [2008-02-20 22:20 UTC] kalle@php.net
Description:
------------
Already now from just playing around with namespaces with the latest CVS version of the PHP_5_3 branch, I found it would be rather useful to add private classes to namespaces that internally works with the namespace and cannot be called from outside the namespace (or root namespace).

Would this possible be a feature of 5.3 final?


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-04-17 03:08 UTC] someone at someone dot com
I agree and support this addition, not just for classes but also functions. Even constants could, though I feel there is no need.

On a side note, namespaces as they are right now are NOT a viable solution. Consider the following:

<?
final class FOO
{
  private __construct () {} // we cannot instantiate

  static public $myVar;
  static private $otherVar;

  static public function MyFunc () { some code }
  static private function OtherFunc () { some code }
}

class MYVAR ()
{
}

FOO::$myVar = new MYVAR();
?>

declaring everything static in a class works pretty much like a namespace would (resolving through :: e.g. FOO::MyFunc()), which is ok but not enough, as there cannot be a class 'MYVAR' definition inside the class 'FOO' (and thus making it internal to 'FOO'), that creates the problem of having the class MYVAR accesible from everywhere

and because of that the namespaces are useful, but not like they are now

consider the following hypotetical syntax:

<?
namespace FOO
{
  public $myVar;
  private $otherVar;

  public function MyFunc () { some code }
  private function OtherFunc () { some code }

  public function Init () { $myVar = new MYVAR(); }

  private class MYVAR ()
  {
  }
}

FOO::Init();
?>

note I put 'private class', but sure it could be something like 'internal' and so on

there are a couple of differences, the first being the namespace confined within brackets '{}' and thus limiting its scope, this allows for initialization code if needed in the same file

the second is of course the public/private/internal/wathever support inside a namespace, so the class 'MYVAR' can only be used internally and thus being invisible to the code outside the namespace 'FOO'

this is pretty handy for categorization of the properties/methods in complex/big php chunks

to serve as an example:

<?
namespace FOO
{
  public $tools;
  public $errors;
  public $info;

  internal $initialized = false;

  internal class TOOLS
  {
    public function CheckSomething () { ... }
    public function CompareSomething () { ... }
    ...
  }

  internal class ERRORS
  {
    public $last;
    public function Clear () { ... }
    public function Count () { ... }
    ...
  }

  internal class INFO
  {
    public $name;
    public $author;
    public $description;
  }

  public function Init ()
  {
    if ( $initialized ) return;

    $tools = new TOOLS ();
    $errors = new ERRORS ();
    $info = new INFO ();

    $initialized = true;
  }
}

FOO::Init ();

echo FOO::$info->name;
echo FOO::$errors->last;
?>

that would make the namespaces truly useful, if it could be done this way (or something similar) the only thing missing would be 'true' properties (readonly anyone??) with the ability to set their read/write operations much like c#... though the readonly would be already a giant step to forget about the stupid get-set pattern

thanks for reading!
 [2008-04-17 03:34 UTC] someone at someone dot com
forgot to tell why I don't consider namespaces really useful right now:

'static classes' works pretty much like namespaces but a couple of differences

1.- inside a 'static class' you can define private things, a namespace cannot
2.- a 'static class' is limited to 1 file in a big block of code, a namespace can be divided in several files if needed
3.- a namespace can define classes inside
4.- a namespace cannot have a initialization code inside its own files but outside, while a 'static class' approach can

the rest is pretty much the same (talking about a programmers perspective), however is much more useful the private vars/functions and the initialization code than the namespace's actual goodies

- with a 'static class' you can have internal switches and status variables, and can initialize itself if needed at the include time
- with a namespace, you cannot have internal switches and status variables unless inside a class definition (which would be public either way, but the vars/methods can be defined as private at least)
moreover a namespace cannot initialize itself, but is dependant on the programmer to call its initialization functions

and so, as of now and even with its limitations, a 'static class' approach is far better namespace than a real namespace (from my point of view of course)

sorry for this 2nd comment
 [2011-04-20 07:25 UTC] netmosfera at gmail dot com
hi kalle
look at this too
http://bugs.php.net/bug.php?id=52297
 [2018-05-05 19:34 UTC] requinix@php.net
-Status: Open +Status: Wont fix -Package: Feature/Change Request +Package: *General Issues
 [2018-05-05 19:34 UTC] requinix@php.net
Marking wontfix due to @aharvey's "beyond the scope" comment in bug #52297
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 21:01:27 2024 UTC