YANP (Yet Another Namespace Proposal) for PHP

[DougBTX]

Although you might be right, please stop promoting this myth.

Where is the myth? Here is the quote from the internals list:

http://news.php.net/php.internals/17332

Files under the directories in the class_path have
the namespace names as directories and the class names named exactly as the
file that declares it (like Java)

(emphasis added)

Douglas

[bonefry]

Where is the myth? Here is the quote from the internals list:

http://news.php.net/php.internals/17332
(emphasis added)

Douglas

Hmm, that sucks.
It doesn't apply to PHP. Namespaces should be available for variables and functions also. Not only for classes.

[Lazesharp]

Hmm, that sucks.
It doesn't apply to PHP. Namespaces should be available for variables and functions also. Not only for classes.

I believe that is the intention of the patch currently being worked on...

[lastcraft]

Hi...

I would like a standard mechanism with which to say
import namespace.class;
and don't worry about the filesystem anymore.

I feel we should keep it down to just namespaces. How about...

add_path('very/long/path'); 

...for this?

Although you could go...

$path = 'very/long/path';
require_once("$path/my_file.php"); 

yours, Marcus

[Dr Livingston]

 $path = 'very/long/path';
require_once("$path/my_file.php"); 

Are you serious Marcus?

[arborint]

 $path = 'very/long/path';
require_once("$path/my_file.php"); 

Are you serious Marcus?

I hope he is serious. That is acutally simple flexible code. I am really missing the point of doing this:

import MyCode:MyClass;
$obj = new MyCode:MyClass(); 

rather than

include 'MyCode/MyClass.php';
$obj = new MyCode_MyClass(); 

It is just to make PHP look more like other languages. Or maybe to add statements that have more side effects to replace ones that have less. I am honestly getting to the point where I think autoload and namespaces might be considered a bad code smell in PHP.

[DougBTX]

$obj = new MyCode_MyClass(); 

If you can set the MyCode part inside the including page, then we have namespace support.

Douglas

[bonefry]

It is just to make PHP look more like other languages. Or maybe to add statements that have more side effects to replace ones that have less. I am honestly getting to the point where I think autoload and namespaces might be considered a bad code smell in PHP.

And maybe now you consider that "the reference" bug is actually normal.
Oh common. It's about a standard mechanism to include modules. I haven't heard of Python programmers complaining about it.
Maybe we should strip PHP of classes too. That way nobody will complain anymore about OOP in PHP.

[mx2k]

you would need to modify the php core when it comes to class identifiers, it doesn't even allow you to do this (bassically use constants or dots)

define("Framework", "Framework_");
define("Web", "Web_");
define("Mail", "Mail");

class Framework_Web_Mail {

}

$x = new Framework.Web.Mail; 

but to those who don't think we need namespaces, if you have ever had to intergrate different projects or code bases of any kind, you know this would come in handy. especially where there people who always use simple class names like user, mail, ui, page, and etc.

plus i wouldn't mind doing something like

imports ui as Framework.Web.UI
$t = new ui.Page

[arborint]

And maybe now you consider that "the reference" bug is actually normal.
I haven't heard of Python programmers complaining about it

You forgot to mark these comments as off-topic.

Oh common. It's about a standard mechanism to include modules. .

I haven't a clue what a "module" is as there is no such thing in PHP. There already is a flexible way to load files.

[arborint]

but to those who don't think we need namespaces, if you have ever had to intergrate different projects or code bases of any kind, you know this would come in handy. especially where there people who always use simple class names like user, mail, ui, page, and etc.

Ultimately what is being advocated here is run-time renaming as a shortcut instead of build-time renaming.

[mordred]

Ultimately what is being advocated here is run-time renaming as a shortcut instead of build-time renaming.

Not following you here. What do you mean with renaming? Namespaces (as I understand them, there are various definitions floating around in this thread) do not rename things, but provide means to avoid clashes of two named entities in the global symbol table of the running script. From what I know they can do this by acting as a layer between two symbol tables. I agree with those that said it's immensely helpful to have such a mechanism at hand if you need to integrate class architecture from different, non-related projects.

For me I would be satisfied if I had a way to alias those entities imported via include(_once) and require_(once), probably in a similar way as Python does. In quasi-code:

 require_once '/path/to/my/project/Database.php' as MyProject;
 $db1 = new MyProject.Database($dsn);
 
 // ...
 
 require_once '/some/other/legacy/framework/DB.php' as Old;
 $db2 = new Old.Database($dsn); 

[arborint]

Not following you here. What do you mean with renaming? Namespaces (as I understand them, there are various definitions floating around in this thread) do not rename things, but provide means to avoid clashes of two named entities in the global symbol table of the running script. From what I know they can do this by acting as a layer between two symbol tables. I agree with those that said it's immensely helpful to have such a mechanism at hand if you need to integrate class architecture from different, non-related projects.

For me I would be satisfied if I had a way to alias those entities imported via include(_once) and require_(once), probably in a similar way as Python does. In quasi-code:

 require_once '/path/to/my/project/Database.php' as MyProject;
 $db1 = new MyProject.Database($dsn);
 
 // ...
 
 require_once '/some/other/legacy/framework/DB.php' as Old;
 $db2 = new Old.Database($dsn); 

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.

Your motivation was that it is "it's immensely helpful to have such a mechanism at hand if you need to integrate class architecture from different, non-related projects." So the focus in on just those cases where there are libraries that one would want to integrate that actually have name clashes your current code. Do you have examples?

[mordred]

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.

No, that's not exactly what I wanted to illustrate with my example. You misunderstand me and my fancy symbol tables.

You could do the same at build time.

Sure, I can add prefixes/suffixes to all class, constant, function, variable names to prevent clashes. But how should I know that my prefix won't clash with a different framework? How do you ensure that? Besides, it's not only the names in the declaration of those variables, but also where they are used, as in function calls/type hinting. Add variable variables and reflection to it and you can change almost every name in your application. Error-prone and a major headache when it comes to refactoring your application.

Your motivation was that it is "it's immensely helpful to have such a mechanism at hand if you need to integrate class architecture from different, non-related projects." So the focus in on just those cases where there are libraries that one would want to integrate that actually have name clashes your current code. Do you have examples?

How much code do you need? Seriously, what's the point of asking for examples - is the problem that hard to understand? But if you really like to know, I have a pet project under development that has a File class. Unfortunately during one exploratory test it clashed with PEAR's File class. So which class name should I have changed at "build" time? The one who is used less in my current system (PEAR::File), or the one that's probably used more by other people (PEAR::File) left untouched? Should both be changed?

May I ask what you think are the reasons that

a) this namespace proposal was made and
b) so many other languages have a concept of namespaces?

[arborint]

Sure, I can add prefixes/suffixes to all class, constant, function, variable names to prevent clashes. But how should I know that my prefix won't clash with a different framework? How do you ensure that? Besides, it's not only the names in the declaration of those variables, but also where they are used, as in function calls/type hinting. Add variable variables and reflection to it and you can change almost every name in your application. Error-prone and a major headache when it comes to refactoring your application.

We you can't ensure that. But you will get the name clash whether you have namespaces or not. Namespaces and renaming are solutions to clashes, not predictors. Would you add the overhead of namespaces if you knew there was no clashes?

How much code do you need? Seriously, what's the point of asking for examples - is the problem that hard to understand? But if you really like to know, I have a pet project under development that has a File class. Unfortunately during one exploratory test it clashed with PEAR's File class. So which class name should I have changed at "build" time? The one who is used less in my current system (PEAR::File), or the one that's probably used more by other people (PEAR::File) left untouched? Should both be changed?

Of course the most practical for you would be for them to rename PEAR. So, so far I have heard of one problem, yours. And what a suprise you must have had to discover that someone else has created a class named "File". Who would have seen that one coming!

May I ask what you think are the reasons that

a) this namespace proposal was made and
b) so many other languages have a concept of namespaces?

Nothing big really. Just sloppy, lazy programmers who would rather patch than do it right and should probably be using a different language.

[Ezku]

define("Framework", "Framework_");
define("Web", "Web_");
define("Mail", "Mail");

class Framework_Web_Mail { }

$x = new Framework.Web.Mail; 

An ugly hack if I ever saw one.

Also, I think __autoload is the worst ideea ever. Just a minor hack of zend to keep unhappy programmers that miss namespaces on board.

And why's that? What's wrong with lazy-loading classes? How does that collide with having namespaces?

Really, what's the problem with having namespaces just as you have the global namespace - with no extra quirks? Lazesharp's solution is so incredibly simple and elegant that I can't really come up with an excuse not to want it done in PHP asap. The prospect of cascading namespaces with __autoloads is something I personally find very enticing.

[DougBTX]

Lazesharp's solution is so incredibly simple and elegant that I can't really come up with an excuse not to want it done in PHP asap.

Come up with a code patch and we'll all love you!

I'm a bit in awe at the moment, some good stuff out there. You can even see a prediction for how basing namespaces on filenames will limit you in ways you can't expect at the outset.

Douglas

[Ezku]

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.

And you could go and code the whole thing in ASM while you're at it.

Your motivation was that it is "it's immensely helpful to have such a mechanism at hand if you need to integrate class architecture from different, non-related projects." So the focus in on just those cases where there are libraries that one would want to integrate that actually have name clashes your current code. Do you have examples?

Namespaces most certainly wouldn't be a mere tool to better integrate foreign class structures. They could be used to chop the sections of a single project to nice, tight bunches with simple class names as an added bonus. I guess this is what they call packages.

A solution such as proposed by Lazesharp would allow you to be simple and merely use namespaces to prevent clashes - and what a relief would that already be -, but also delve in deeper and devise a neat little package management system customized to accommodate any and all structures you can just come to think of. I honestly can't see why you're opposing this so firmly.

[mx2k]

An ugly hack if I ever saw one.

i was just playing around with the identifier to see what i could get away with because technically you can concatinate strings & constants using dots, and i was wondering if would be possible to do this with class identifier, buts its not. I'm not a huge fan of underscores.

[DougBTX]

I'm not a huge fan of underscores.

That's something I dislike about Python.

[arborint]

And you could go and code the whole thing in ASM while you're at it.
Namespaces most certainly wouldn't be a mere tool to better integrate foreign class structures. They could be used to chop the sections of a single project to nice, tight bunches with simple class names as an added bonus. I guess this is what they call packages.

A solution such as proposed by Lazesharp would allow you to be simple and merely use namespaces to prevent clashes - and what a relief would that already be -, but also delve in deeper and devise a neat little package management system customized to accommodate any and all structures you can just come to think of. I honestly can't see why you're opposing this so firmly.

I'm not opposing this. I just haven't seen it as very necessary. It is a optional feature that people who think namespaces are neat will use, but that's about it.

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(); 

Bboth 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.

[arborint]

Originally Posted by mx2k
I'm not a huge fan of underscores.

That's something I dislike about Python.

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.

[Radley]

Namespace name clashes happen rarely as opposed to having all of your classes in a global scope.

If you do have a namespace name clash it is a lot easier to change one line of code than many lines of code depending on how many classes you have.

Also having an import directive saves typing for when the benefits of using namespaces are not neccesary.

However with this model

require 'database.php' as NewDb;
require 'database_old.php' as OldDb;

$conn = new NewDb:DatabaseConnection(...);
$conn = new OldDb:DatabaseConnection(...); 

don't the problems above diminish? Import would be redunant too; if you didn't have name clashes just ignore the 'as' parameter.

Namespaces in any implementation reduce renaming by giving a set of classes a (most of the time) unique identification while the classes could have commonly used names.

[33degrees]

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

[arborint]

If you do have a namespace name clash it is a lot easier to change one line of code than many lines of code depending on how many classes you have.

Also having an import directive saves typing for when the benefits of using namespaces are not neccesary.

However with this model

require 'database.php' as NewDb;
require 'database_old.php' as OldDb;

$conn = new NewDb:DatabaseConnection(...);
$conn = new OldDb:DatabaseConnection(...); 

don't the problems above diminish? Import would be redunant too; if you didn't have name clashes just ignore the 'as' parameter.

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. Again the above code strikes me as less clear than:

require 'database.php';
require 'database_old.php';

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

Namespaces in any implementation reduce renaming by giving a set of classes a (most of the time) unique identification while the classes could have commonly used names.

As I showed above namespaces really don't reduce renaming, nor do they really allow use of "common" names because when you use the class you are just swapping underscores for colons.

It seems that what namespaces are really for is kludging together two or more codebases that have name clashes that for some reason cannot rename. This makes more sense for compiled libraries and non-open source code obviously. And I really don't buy the notion that you require a new lanugage construct because you want to use a PEAR class and your own classes but they must have the same names. Namespaces are not more convenient, nor clearer, nor faster ... they are a workaround and should be considered as such.

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

I still think my tildes are prettier.