YANP (Yet Another Namespace Proposal) for PHP

[BerislavLopac]

Well you can talk about your fancy symbol tables all you want, but all your example is doing is, at run-time, is renaming Database (in Database.php) to MyProject.Database and renaming Database (DB.php) to MyProject.Database. You could do the same at build time.

But in PHP, there is no difference between build time and run time, they are one and the same.

[arborint]

But in PHP, there is no difference between build time and run time, they are one and the same.

I wasn't using "build-time" in the compiled/linked language sense. By "build-time" I meant when you are building the application, running unit tests, deployment scripts, etc.

[Lazesharp]

My point is that if either way you have to change your code to avoid namespace clashes. Say you start with this code:

class File{
    function __construct() { echo 'File'; }
} 

and you discover that you have a name clash, you can either do:

namespace foo {
    class File{
        function __construct() { echo 'foo:File'; }
    }
}

$foo = new foo:File(); 

or you can do:

class foo_File {
    function __construct() { echo 'foo_File'; }
}

$foo = new foo_File(); 

Both require a change, neither protects you more from namespace clashes, and the namespace solution is more verbose. I just can't get excited about using colons instead of underscores. And the reasons given are things like "I haven't heard of Python programmers complaining about it" or "go and code the whole thing in ASM while you're at it" which are not too persuasive.

Consider the following:

<?php
require_once('foo/file.class.php');

$obj = new foo_file();
?>

Now imagine that in use in a full script, and with many classes, all being referred to with the _ notation.

Now consider this:

<?php
require_once('foo/file.class.php');

import foo:class;
// or even import foo:*;

$obj = new file();
?>

Now imagine working with many different namespaces, some of which are nested. I know which i'd rather.

Namespaces, as has been pointed out by the PHP development team many times, are a syntactical nicety. They are by no means 'required', but that doesn't make them any less useful. The problem at the moment is that the bulk of the proposed solutions involve imposing a full-blown package management system on anyone opting to use namespaces, which many people won't want and also makes the solution harder to create.

Incidentally, just because it's good practice to have classes in their own discrete files, there's nothing wrong with declaring a class in the same file as some procedural code, or multiple classes in the same file neither should there be anything wrong with this.

Filesystem structure should be decided in userland, not by any namespace system. I'm tempted to go learn some C, the Zend API and code up a proof-of-concept patch based on Jessies earlier work actually.

[pachanga]

I don't see anything diminishing. If I just rename the "old" database class name there are two changes (one inside database_old.php and the other for the new statement). The code above requires two changes as well

With namespace support you don't have to rename original classes. Well one is still required to resolve name clashes(if any) using long names prefixed with namespaces but there's no need to sed through lots of files renaming 'Foo' to 'Old_Foo'. And what if one has strict file naming convention, e.g. class 'Foo' is stored in 'Foo.class.php'? Does one need to change it to 'Old_Foo.class.php' also? That's way too much fuss...

[DougBTX]

class File{
    function __construct() { echo 'File'; }
} 

and you discover that you have a name clash, you can either do:

namespace foo {
    class File{
        function __construct() { echo 'foo:File'; }
    }
}

$foo = new foo:File(); 

or you can do:

class foo_File {
    function __construct() { echo 'foo_File'; }
}

$foo = new foo_File(); 

Both require a change, neither protects you more from namespace clashes, and the namespace solution is more verbose.

If it doesn't stop name clashes, it isn't a namespace is it? You are getting package name clashes, not namespace clashes. That's the problem with the patch.

For namespaces to give you something more than prefixing, they must work in such a way that File can be defined the same way, regardless of which namespace it is in:

class File {
    function __construct() { echo 'File'; }
} 

You only ever use the name of the namespace once you are outside it, because when you are inside, you are always inside it, regardless of the name. Every class should think that it is in a nameless namespace, though classes outside the namespace should know better.

With the example:

require 'dev/database.php'; 
require 'classes/database.php'; 

$conn = new DatabaseConnection(...); 
$conn = new Old_DatabaseConnection(...); 

You forget thay Old_DatabaseConnection could be used in other files, so you have n places to update the name, and then another n places to update again once your new DatabaseConnection is working.

Douglas

[DougBTX]

The objectivity of all this discourse is quite impressive. I was going to recommend tildes which I find quite beautifully wave-like. I'm a much bigger fan of them than all those dotty colons and periods.

I said it was something I didn't like, not something that would stop me using it

And besides, tides are unreliable, some fonts they are up, some fonts they are in the middle. And I'd like to save them for when PHP supports native regexes, "return fase if foo =~ /[bar]+/"

Douglas

[Lazesharp]

And I'd like to save them for when PHP supports native regexes, "return fase if foo =~ /[bar]+/"

Off Topic:

"When"... Wishful thinking. That's be nice, but I think PHP should look to support PCRE 6 first (assuming the PCRE library actually gets updated in line with Perl).

[lastcraft]

Hi...

I know this is probably trivial, but those single colons really bug me....wouldn't it make more sense to be double colons?

Well, it's one less character to type.

Regarding the Python solution being elegant I don't think that is true. Reusing the filesystemas your namespaces may seem efficient, but it's like using my toaster as a magazine rack. You can only really overload functionality if there is never going to be a conflict. That's why inheritance gets you into such a mess - commonoality of code doesn't always corespond to commonality of purpose.

I am no Python expert, but I can see lot's of hidden complication. For example in Python, how do you manage relative paths? How do you handle multiple versions? How do you refactor when moving a class from one package to another. That these answers are not obvious, and have to be explained, is pretty damning from the elegance point of view.

It may seem elegant from a coding angle, but it's anything but when viewed from a management and configuration angle. Namespaces are about large projects and you have to have large project thinking.

yours, Marcus

[Lazesharp]

Regarding the Python solution being elegant I don't think that is true. Reusing the filesystemas your namespaces may seem efficient, but it's like using my toaster as a magazine rack. You can only really overload functionality if there is never going to be a conflict. That's why inheritance gets you into such a mess - commonoality of code doesn't always corespond to commonality of purpose.

I am no Python expert, but I can see lot's of hidden complication. For example in Python, how do you manage relative paths? How do you handle multiple versions? How do you refactor when moving a class from one package to another. That these answers are not obvious, and have to be explained, is pretty damning from the elegance point of view.

It may seem elegant from a coding angle, but it's anything but when viewed from a management and configuration angle. Namespaces are about large projects and you have to have large project thinking.

Off Topic:

I like your way of thinking....

*glances at PHPLondon*

Whenever I look back at the solution on the internals list, or indeed some of the ideas floating around on this topic, I get this horrible sick feeling in the pit of my stomach that this patch is being developed purely for the sake of adding namespaces.

Namespace support in PHP should be developed to solve a problem, not for the sake of adding namespaces.

It's this way of thinking that has led me to advocate the much simpler idea that namespaces should be a means of separating groups of classes and the import keyword should do nothing more than import a namespace (or class from a namespace) into the current symbol table (be that the global one or another namespace).

[sweatje]

And I'd like to save them for when PHP supports native regexes, "return fase if foo =~ /[bar]+/"

Douglas

Perl bigot

[DougBTX]

It's this way of thinking that has led me to advocate the much simpler idea that namespaces should be a means of separating groups of classes and the import keyword should do nothing more than import a namespace (or class from a namespace) into the current symbol table (be that the global one or another namespace).

It is easier from userland PHP, which is what we want, but from an internals point of view it is nowhere near as simple as prefixing class names, whether in userland as arborint suggests or internally as the pach above does.

I knwo this is the wrong place to ask, but internally, where do classes go in the symbol table, and how much symbol handling code needs to be rewritten to support multiple tables?

Currently we have code like this, it looks like classes are just global. Could be lots of code to change...

function foo() {
  class Bar {
    function talk() {
      echo 'hi world';
    }
  }
}

$bar = new Bar; // Class Bar not found

foo();

$bar = new Bar;
$bar->talk(); 

Douglas

[Lazesharp]

I knwo this is the wrong place to ask, but internally, where do classes go in the symbol table, and how much symbol handling code needs to be rewritten to support multiple tables?

I believe currently the patch being written uses two hash tables, one that contains all declared classes (already part of PHP) and a new one that contains all the declared namespaces (iirc). As far as I know, when you declare a class within a namespace, it adds it to the classes hash table with the full URI to that class (e.g. 'ns:class'). I'm not sure exactly how it handles it, but it seems to do ok.

The current patch actually looks to handle things rather well, but then the author started talking about imposing file structure rules, introducing a new php.ini directive (class_path) and automatically including the files whenever 'import' is called. Eurgh!

Thankfully, it seems that all or most of those responsabilities are now going to be (rightfully) delegated to __autoload.

[DougBTX]

Perl bigot

That there is Ruby

[sweatje]

That there is Ruby

Yes, but it is a Ruby Perlism, and I know where your true loyalties lie

You know you can have your PHP card revoked for suggesting regex become first class citizens, right? "That thar' is line noise"

[arborint]

Whenever I look back at the solution on the internals list, or indeed some of the ideas floating around on this topic, I get this horrible sick feeling in the pit of my stomach that this patch is being developed purely for the sake of adding namespaces.

Namespace support in PHP should be developed to solve a problem, not for the sake of adding namespaces.

This is my point exactly. There seem to be people who just think namespaces are cool, when in fact they add complexity to code that is unnecessary except for maybe a few rare cases. The idea if having a class that is called by different names in different programs (or even the same program) sounds like a recipe to create more problems than it solves.

I can't think of a reason to use namespaces to develop new code unless people are serious about liking colons better than underscores. Namespaces may have some use in integrating legacy code, but I still fail to see where renaming wouldn't be a better solution. The contribution of a librarian/packager utility that could maintain multiple files and do kind of renaming across all files would probably be a better contribution to PHP than namespaces.

[mx2k]

Namespaces are helpful when organizing & grouping classes together, preventing name clashing with other code, and helps to prevent having to retype elongated class names.

you want your code to be descriptive and readable, but at the same time not overally verbose. You also want to be able to have things in chunks & units to increase the ability to maintain your code.

And i know that not everyone uses an IDE, but this would also help with not having all your project classes loaded at once for autocomplete, and can be a pain to scroll through all those names and underscores.

and it would be nice to have namespaces not tied to the file structure. This could be useful in code libraries or frameworks, but i don't see how this would help the website folder structure or if you're team or yourself already has a set method of directory structure.

maybe possibly and optionally function that could look up one designated file with all the includes/requires for that namespace if you importing the whole namespace rather than just the class.

imports MyFramework.Web;

[Lazesharp]

I can't think of a reason to use namespaces to develop new code unless people are serious about liking colons better than underscores. Namespaces may have some use in integrating legacy code, but I still fail to see where renaming wouldn't be a better solution.

The only real advantage is that you can do this:

namespace foo {
    class bar {}
}

// Import into current namespace
namespace test1 {
    import foo:*;

    $obj = new bar();
}

// Use full URI instead
namespace test2 {
    $obj = new foo:bar();
} 

If you think about the applications for this in the real world, especially larger applications and anything that is redistributable (frameworks, PEAR packages etc.). Namespaces are fundamentally different from simply renaming, yet they do serve a similar purpose.

[Lazesharp]

maybe possibly and optionally function that could look up one designated file with all the includes/requires for that namespace if you importing the whole namespace rather than just the class.

imports MyFramework.Web;

__autoload() does just that in the current implementation of the solution.

[mx2k]

__autoload() does just that in the current implementation of the solution.

yes, but it becomes a little more tricky if you have classes under the same name space in difference folders seperated by layers rather by naming convention or some other kind of folder structure. Autoload could become a nightmare of a function, especially for maintainability.

[Lazesharp]

Then use require_once instead and load all the files for a namespace manually. I don't see the problem with it all, I rarely use __autoload() at all (infact, I don't aside from a simple dependancy resolution system that uses it).

For the record, it's not bad practice to use require/include...

[bonefry]

Then use require_once instead and load all the files for a namespace manually. I don't see the problem with it all, I rarely use __autoload() at all (infact, I don't aside from a simple dependancy resolution system that uses it).

For the record, it's not bad practice to use require/include...

You're missing the point. That doesn't solve the problem.

[Lazesharp]

I understand problem, I just fail to see how namespaces causes it, surely it's a problem that would exist even without namespace support.

[mx2k]

actually require/includes or autoload isn't a problem, i was just simply suggesting extra hooks to help keep things managable. the point was, namespaces help to manage code internally and to keep things organized, especially dealing with larger projects.

[Dr Livingston]

I don't like to use require_once() as there is no way clean way to deal with the failure of the file fetch. If the file is not fetchable, you get an error, which not only ugly, it's a security risk.

Sure, you could mask the error being displayed, but where do you go from there huh? Do you use something like this for each file required...

if( !file_exists( ... ) ) { 
... report and log error ...
}
require_once( ... ); 

I just think we need something a bit more sophisticated that your average require_once(), that's all. __autoload is a start but it's not entirely a complete solution

[Lazesharp]

Easy!

function require_once_facade() {
    // Code to handle loading and failing of requires
} 

Of course, without being so crude, but you get the idea.