YANP (Yet Another Namespace Proposal) for PHP

[stereofrog]

Hmm, as Marcus says, "everything is done at parsing time". So, a proof of concept could just be a function like this:

function require_in($file, $namespace) {
  $content = file_get_contents($file);
  $content = str_replace('all_class_names',
                         "$namespace_all_class_names",
                         $content);
  eval($content);
} 

The tricky line is line 3, any ideas?

For example,

$kls = 0;
$out = "";
foreach(token_get_all($src) as $tok) {
    if(is_array($tok)) {
        if($tok[0] == T_STRING && $kls)
            $out .= "prefix_";
        if($tok[0] != T_WHITESPACE)
            $kls  = ($tok[0] == T_CLASS);
        $out .= $tok[1];
    } else
        $out .= $tok;
} 

[DougBTX]

Somehow I understood it would - there's no point to the whole thing if it doesn't.

There is nothing along those lines in the test cases, includes are done like this:

ini_set( 'class_path', dirname( __FILE__ ) . '/namespace' );

import ns:class1;
import ns:class2 as ns_class2;

$full = new ns:class1();
var_dump( $full->mem1 );

$alias = new class1();
var_dump( $alias->mem1 );

$alias2 = new ns_class2();
var_dump( $alias2->mem2 ); 

Where /namespace has a folder called 'ns' which contains class1.php, class2.php etc. In the testcase there is ambiguity as to whether the ns: comes from the namespace in class1.php, or from the filesystem.

Douglas

[lastcraft]

Hi...

Thanks chaps. I was once going to write a proof of concept in PHP along the lines you are going. I feel the real version should be at the language level, but a pure PHP solution would give a point of discussion. Here are myrandom accumulated thoughts that have been knocking around in my head for a while.

You could simply have the namespace along PEAR lines for a pure PHP hack...

$a = new MyName_A(); 

...as that would be compatible with the conventions out there. It also means that classes that already have that format could be skipped by the namespacing operation or simply have the names changed.

$object = new Pear_Object(); 

...could become...

$object = MyNamespace_Object(); 

Regarding nested includes...

If there are any requires_in()'s inside the imported library, then that namespace should stand. While class names can clash, it should be relatively easy to avoid namespace nameclashes. I don't see the need for...

$d = new A:B:C:D(); 

Also, if a file has been included before globally, then it should not be namespaced. I mean the exact location (not just the filename). This is to prevent common classes being loaded a ridiculous number of times. Does PHP keep a list of required files anywhere?

Rgarding eval(), you don't need it. You would need a cache anyway, so just copy the modified source into the cache and require() it from there (you get require_once() for free this way). If you are using an accelerator, this takes away the performance impact of eval().

yours, Marcus

[bonefry]

I don't see the need for...
$d = new A:B:C();

Are you sure ? If they do it once, they'd better do it right and not place such restraints.

Also, I like how namespace are implemented in Python were a namespace is a directory.
So, if we want to use a namespace:

import namespace
obj = namespace.object()

or

from namespace import object
obj = obiect()

were namespace is a directory like this:

..
__init__.py
object.py

were the file __init__.py is executed when the module is imported and it's not required.

I think this could be a good namespace model for PHP.

[Ryan Wray]

Does PHP keep a list of required files anywhere?

Yes, you can get an array of included files from the function get_include_files().

[Ezku]

Also, I like how namespace are implemented in Python were a namespace is a directory.

I think this could be a good namespace model for PHP.

That's certainly interesting! So in PHP we'd set a class directory that contains those "namespaces" that are actually mere subdirectories. Seems intuitive and handy; there's no namespace foo { } cluttering the code. This'd get us nested namespaces on the side.

[lastcraft]

Hi...

Also, I like how namespace are implemented in Python were a namespace is a directory.

Frankly I find it ghastly and it's the most annoying thing moving from C++ to Java . It means everytime a class changes package you have to shuffle a load of files about as well. And it's just unnecessary. Why pull a restriction out of thin air for no identifiable gain. Hm, programmers have a habit of over organising at the best of times...

Another problem occours when you want your test scripts in the same package as the classes. OK, that's a problem peculiar to java scopes (and you can get around it with a parallel directory structure in Java), but it prevents you having a simple classes folder or tests folder for smaller projects. And that's just the beginning.

I don't think a simple thing like namespaces should dictate the build structure of a project. Anyway, how do you ensure compatibility with the code already out there. The point of namespaces is to allow libraries to interoperate. Hardly much use if that doesn't work.

Again I think there is a real different between namespaces, a means of managing external code, and packages, which are an internal project structure.

yours, Marcus

[arborint]

Back to PHP namespaces...

What does the patch look like in practice? What sort of code do you write with the namespace patch?

yours, Marcus

I read through this rather drivelly thread again and I didn't see where anyone had answered Marcus' obvious question of what code using the namespace patch actually look like. Was it just lost in the *absolutely facinating* LanguageX is more readable than LanguageY posts?

[DougBTX]

I read through this rather drivelly thread again and I didn't see where anyone had answered Marcus' obvious question of what code using the namespace patch actually look like.

Try post 41 back on page 2: http://www.sitepoint.com/forums/show...9&postcount=41

There isn't much to say, except ***** about PHP. Even Marcus did it!

The code looks like this:

namespace ns 
{ 
        class class1 
        { 
                public $mem1 = 1; 
        } 
} 

And I'd say another +1 for file structure shouldn't depict application structure, and vice versa. Soon you'll be saying we should only ever have one class per PHP file.

What if I wanted to use the same class in two different places in my code under different namespaces? I think a full solution would have to be able to handle that.

Later,
Douglas

[arborint]

Try post 41 back on page 2: http://www.sitepoint.com/forums/show...9&postcount=41

There isn't much to say, except ***** about PHP. Even Marcus did it!

The code looks like this:

namespace ns 
{ 
        class class1 
        { 
                public $mem1 = 1; 
        } 
} 

Does that mean, for example, I could do:

MyDB.php

namespace MyCode {
    class DB {
    ....
    }
} 

And then:

include 'DB.php';    // from PEAR
include 'mycode/MyDB.php';
$peardb = new DB();
$mydb = new MyCode:DB(); 

Or is it:

include 'DB.php';    // from PEAR
include 'mycode/MyDB.php';
$peardb = new DB();
namespace MyCode {
    $mydb = new DB();
} 

[DougBTX]

Here's how think the patch works (baring in mind my C is rusty and I'm unfamiliar with the PHP source..)

When you do namespace ns { }, a global is set to the current namespace:

+void zend_do_begin_namespace(znode *ns_token, znode *ns_name TSRMLS_DC)
+{
+	/* allocate space for the namespace prefix */
+	CG(namespace_prefix) = emalloc(ns_name->u.constant.value.str.len + 2);
+
+	/* get the namespace prefix */
+	strncpy(CG(namespace_prefix), ns_name->u.constant.value.str.val, ns_name->u.constant.value.str.len + 1);
+	strcat(CG(namespace_prefix), ":");
+
+	/* get the lowercased namespace prefix */
+	CG(namespace_prefix_lc) = zend_str_tolower_dup(CG(namespace_prefix), ns_name->u.constant.value.str.len + 1);
+
+	/* save the prefix length */
+	CG(namespace_prefix_len) = ns_name->u.constant.value.str.len + 1;
+}

The global is then used to rename the class if it is set:

+void zend_prefix_class_name_node(znode *class_name TSRMLS_DC)
+{
+	zend_uint new_length = 0;
+	char *org_class_name = NULL;
+
+	if (CG(namespace_prefix) != NULL) {
+		new_length = CG(namespace_prefix_len) + class_name->u.constant.value.str.len;
+		org_class_name = estrdup(class_name->u.constant.value.str.val);
+
+		STR_REALLOC(class_name->u.constant.value.str.val, new_length + 1);
+
+		/* get the full class name */
+		strncpy(class_name->u.constant.value.str.val, CG(namespace_prefix), CG(namespace_prefix_len) + 1);
+		strcat(class_name->u.constant.value.str.val, org_class_name);
+
+		/* get the new string length */
+		class_name->u.constant.value.str.len = new_length;
+
+		efree(org_class_name);
+	}
+}

So, "yes".

Regards,
Douglas

[DougBTX]

It seems, import 'foo:bar' seems to transplate directly to "include foo/bar.php". Example:

+	/* copy the class name to the include file string, replacing colons with
+	   slashes */
+	for (; *class_name != '\0'; ++class_name, ++include_file_ptr)
+	{
+		if (*class_name != ':') {
+			*include_file_ptr = *class_name;
+		} else {
+			*include_file_ptr = '/';
+		}
+	}
+
+	/* add the .php extension */
+	strcpy(include_file_ptr, ".php");

huh?

Douglas

Edit: and, oh gosh, I'll have to delete this post, code in a language that isn't PHP! The Horror! The Shame!

[arborint]

It seems, import 'foo:bar' seems to transplate directly to "include foo/bar.php". Example:

It is namespace plus import? So it essentially turns

import MyCode:MyDB.php;
$mydb = new MyCode:DB(); 

Into:

include 'MyCode/DB.php';
$mydb = new MyCode_DB(); 

How apparently unhelpful. Nothing like adding overhead to do something I could do more clearly myself. Plus adding a bunch of internal rewriting of names which doesn't seem problematic at all. Was this fired off by the same blind archer who shot autoload in the general direction of PHP? Given enough time we should have several overlapping features here that will have to be depricated in PHP6.

[bonefry]

Frankly I find it ghastly and it's the most annoying thing moving from C++ to Java . It means everytime a class changes package you have to shuffle a load of files about as well. And it's just unnecessary. Why pull a restriction out of thin air for no identifiable gain. Hm, programmers have a habit of over organising at the best of times...

Another problem occours when you want your test scripts in the same package as the classes. OK, that's a problem peculiar to java scopes (and you can get around it with a parallel directory structure in Java), but it prevents you having a simple classes folder or tests folder for smaller projects. And that's just the beginning.

I don't think a simple thing like namespaces should dictate the build structure of a project. Anyway, how do you ensure compatibility with the code already out there. The point of namespaces is to allow libraries to interoperate. Hardly much use if that doesn't work.

Again I think there is a real different between namespaces, a means of managing external code, and packages, which are an internal project structure.

BTW: a package is a namespace in Java. And the directory structure is necessary to avoid filename clashes. Furthermore, it would be compatible with the current PEAR directory organization. Furthermore, I hate Java style package {} declarations.

I haven't explained much better about modules in Python. Let me explain again. But this time I will do it in PHP (somewhat).

// So we have the a directory called util
// that has 2 files: [i]__init.php[/i] and [i]sys.php[/i]
// [i]__init.php[/i] - is executed when the module has been imported
// [i]sys.php[/i] has the following structure:

$path = array();

class MyClass {
   // implementation here ...
}

// ************
// So, if we want to use MyClass and $path from another file
// we would do something like this:

import util.sys;

echo util:sys:$path;
$object = new util:sys:MyClass();

// or something like this

from util import sys;

echo sys:$path;
$object = new sys:MyClass();

// or something like this

from util.sys import *

echo $path;
$object = new MyClass(); 

Namespaces are a complicated problem, and they can't have a simple answer.

[wdeboer]

Namespaces aren't difficuilt, the main problem is the crappy PHP code

[lastcraft]

Hi...

Namespaces are a complicated problem, and they can't have a simple answer.

I think you see it as difficult, becuase you are conflating two mechanisms.

Package scoping and namespaces have tremendous overlap, and so languages typically only have one mechanism or the other. This means each system will be abused to cover the role of the other. Java has a package system of one package per file and one public class per package, complete with scope rules to match.

The namespace behaviour is pretty incidental. It's a global (real world sense) property where the namespaces are declared with a common root by teh package author, typically an inverted URL. This is just a string prefix though, and has nothing to with a file system. In that sense Java has both mechanisms, but the namespace part does not live independently of the packages.

C++ has a namespace system. There is no protection within it, it's just there to stop nameclashes.

In a PHP app. you only run a single top level script from many in the appication. This makes PHP packaging both harder and less necessary. However there are a lot of libraries out there with similar goals (template engine anybody) and code that is not currently namespaced.

We need namespaces, not packages.

yours, Marcus

[Lazesharp]

Hello everyone, while this is my first post, i'm no stranger to PHP and regularly read sitepoint.

I'm quite amazed at how much everyone seems to over complicate something that could essentially be so simple. It seems like people are trying to base the PHP object model on Java completely. Yes it has some similarities, but read: PHP is not Java, and never will be.

This is an important point because it seems that this is the best reason for people wishing to tie application structure to namespaces. I agree with lastcraft that namespaces should by no means dictate application structure and I feel that this might well be reflected by the PHP core developers when they were developing "Namespaces" in the early 5.0 betas (note: they called them namespaces, not packages).

Down to the real point here: It's my general belief that trying to auto-include files for namespace imports is just making things harder for everyone. For me the term "import" with relation to namespaces means and has always meant simply to import a single class from (or contents of) a namespace into the global scope. There is no overwhelming reason why a namespace import should trigger an arbitrary require_once(), what's wrong with requiring the files yourself? If you take a look at C# (possible C++/VB.NETs namespace models too, but since I haven't used them I can't give them as examples) you'll notice that the structure of the files has nothing to do with namespaces, and whats more, they call them "namespaces" not "packages" (emphasising lastcrafts point here).

In short, I believe that PHP namespaces would be hugely valuable in preventing naming conflicts and generally allowing developers to use simpler class names. All I want out of namespaces, is to be able to do this:

foo.php

<?php
namespace foo {
    class test {
        function __construct() { echo 'foo:test'; }
    }
}
?>

bar.php

<?php
namespace bar {
    class test {
        function __construct() { echo 'bar:test'; }
    }
}
?>

test.php

<?php
require_once("foo.php");
require_once("bar.php");

// Create object without importing into the global scope
$test = new foo:test();

// Import into global scope then create object
// import foo:* would have a similar effect in this example, that's fairly self-explanatory.
import foo:test;
$test = new test();

// Triggers a Parse error "Cannot redefine class" etc.
import bar:test;
?>

And if you're too lazy to sort out the requires yourself? Use __autoload (and if you have any sense, cache the generated requires in a PHP file for future use since __autoload introduces overhead).

I see no reason for namespaces to have anything to do with paths, if the developer of this current patch continues along these lines, it'll eventually die and we won't see namespaces for a very long time. I'm quite tempted to post to internals with a summary of the thoughts i've posted here.

PHP isn't a toaster.

Disclaimer: I haven't re-read anything i've written and I've been writing fairly quickly, so I might not have been particularly clear and more importantly, I might have come across as having a nasty tone, this was not my intention at all.

[Lazesharp]

Small additional note, if namespaces were logically as simple as my proposal, there'd be no problem with nesting namespaces (which many people would find useful for Frameworks or public APIs where they could have many layers e.g. MyFramework:Controller:FrontController could be the class URI for a FrontController Class in an MVC framework).

[wdeboer]

Well, I am against the use of include_path and __autoload() for this namespace support, even if I have to rewrite PHP... I would still prefer that over the current suggestion <g>

[Ezku]

Use __autoload (and if you have any sense, cache the generated requires in a PHP file for future use since __autoload introduces overhead).

Is the difference really that significant? Any statistics on that?

I liked what you said there. This approach has all we need with PHP.

Multiple autoloads! Oh, joy!

namespace Controller
{
    function __autoload($class) {
        $path = PATH_FRAMEWORK.'/controllers/'.$class.'.php';
        return (file_exists($path) && (include_once $path))
    }
} 

Purdy... mmm.

[Lazesharp]

Is the difference really that significant? Any statistics on that?

I liked what you said there. This approach has all we need with PHP.

Very little to be honest, for most people, __autoload would be fine on it's own, but if you're very picky about performance, it'd be the best way to go, especially if you have a lot of globally included files without explicitly using include/require.

Something like this would illustrate it's use better:

<?php
function __autoload($class) {
    // Code to locate class, assume it fills $classpath with path to file.  
    // Append require_once to this file
    $handle = fopen(__FILE__, 'a');
    if (fwrite($handle, "require_once($classpath);\n") === TRUE)
        require_once($classpath);
    else
        throw new Exception("Can't write to cache");
}
?>

Obviously with some better error handling etc. but you get the idea.

[bonefry]

I'm quite amazed at how much everyone seems to over complicate something that could essentially be so simple. It seems like people are trying to base the PHP object model on Java completely.

Hy Lazesharp,

Although you might be right, please stop promoting this myth. I am also a Java/C++/Python programmer and I don't quite understand from were the ideea that PHP promotes Java object model emerged.

The reason why I said Python style modules could be good for PHP (and please note Python is in no way related to Java) is that I don't like
require "/long/file/path/that/could/change/class.php";

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

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

[wdeboer]

Oh well, I am working on my own implementation of namespaces, in PHP now. Rewriting two small parts of the PHP codebase :+

[Lazesharp]

Hello bonefry,

My statement that people appear to confuse Java and PHPs object-model was by no means influenced by your posts above. Generally aspects of PHP 5s object-model HAVE been inspired by Java (if you look at most of the features on the www.php.net/oop5 page, you'll notice that most are almost exactly the same as what Java is capable of). I was merely stating that treating PHP as though it IS Java is wrong.

I by no means meant that Java is the _only_ language that ties packages to paths, I merely meant that people have decided to copy "how Java has done it" when thinking how to go about it in PHP.

With regards to __autoload, it's not a replacement for namespaces, personally, I dislike it in some ways, because I think it's bad practice to rely on it, but like it in others, in that it allows a slightly more flexible approach to including files (see my example about caching requires using autoload above).

In response to your point about long paths, I agree, long paths are nasty, all the more reason not to tie imports to a path system, because everyone does it differently. Instead have a single __autoload that dictates the namespace-class-path relationships and whenever the paths change, you have a single piece of code to update.

Example time:

Lets assume the style of namespaces i described above. The following script would trigger __autoload('ns:class')

<?php
$obj = new ns:class();
?>

Lets also assume that an __autoload function has already been defined in the global scope as follows:

<?php
function __autoload($uri) {
    // Class could contain a full namespace URI
    // We want the path format to be ns1/ns2/ns3/.../nsN/classname.php
    $path = str_replace(':', '/', $uri) . '.php';

    // $path would now be ns/class.php so we require it if it exists
    if (file_exists($path))
        require_once($path);
}
?>

Of course, the logic for such an autoload could be very simple, or very complex, it would very much be dependant on the complexity of your application structure. The important point here is that it would allow the user to decide how to structure things, PHP is a very dynamic and highly versatile language. Implementing this in userland would actually be the best way to go about binding paths to a class/namespace.

[BerislavLopac]

Re __autoload: I have found it fitting nicely into my style of code organization, but I agree that one should not rely on it.

I have created a PHP5 Singleton class called Classloader, which is used by the __autoload() to include a class file when a class is needed. However, in order to use it you must first register the path to the library where the class file is located, which is then added to the include_path variable. So you get all the benefits: classes are organized one per file, you don't have to explicitly include each class (particularly useful with large libraries) and at the same time it is clear in the code what libraries a class needs. When it comes to third-party libraries which don't follow my organization schema (e.g. ADOdb or SimpleTest) they can easily be included the usual way.