[PATCH] Namespace Patch, Alpha 3 View as Markdown

Hello Jessie,

Wednesday, July 20, 2005, 8:35:26 PM, you wrote:

"Marcus Boerger" mail@marcus-boerger.de wrote in message
news:681697173.20050720083643@marcus-boerger.de...

Please don't add new ini settings here, living with include_path should be
enough, wouldn't it?

Do we want the import behavior to apply to the existing include path? To me,
it seems nice to have the include_path and class_path separate. The
class_path will only be used for classes, and include_path for everything
else (header/footer code, etc.). Of course, this is just my opinion. What
does everyone else think?

Why can't __autoload decide itself? I mean either it knows it received a
namespace class since the string contains a ':' or the function writer
has to find out himself.

Well, when a full namespace import is done, the string will not contain a
':'. __autoload would only receive a class name, and there is no easy way
for __autoload to know which namespace contains that class. That's why a
separate mechanism is needed from __autoload, that will look into the
class_path directories (appending the directories for the namespace name)
for the class file, and if/when found, include that. This is one other
reason why a separate class_path variable would be useful: the include_path
might have several directories, and all these would need to be searched,
even though these directories might not have classes at all. In contrast,
the directories in class_path are specifically for class files, so the
searches are faster.

might, might, might only assumptions with the big drawback of adding another
ini setting. My assumption is that i only need one or two include/class
patchs and that they are of course the same since i want to keep my
application files together - for working maintanance for one reason.
Also if __autoload cannot easily get the requested namespace name than a
compilcated solution has to be worked out since otherwise you end up in
nightmare of naming conflicts - how should you know in a situation where
a classname exists in multiple namespaces from which directory to load?
By order of directory? In the end nothing here would really work around the
problem thus we need the full name.

Best regards,
Marcus mailto:mail@marcus-boerger.de

Marcus Boerger wrote:

You already have the ability to overload __autoload or provide several
userspace __autoload functions that would be called one after another
until the first succeeds. What else do you want? Besides the fact that
i am still convinced that we should find a way to pass the full namespaced
name to __autoload instead of just the classname. If you ask me not doing
so is simply an error.

I still think that the namespace importing logic/file-naming convention is
the cleanest, but if __autoload is to be used, then I currently see three
approaches to this:

1. Search in each directory in the class_path (or include_path) for
   "namespace-name/class-name.php". When the first file is found, then the
   full class name will be generated from that and passed on to __autoload,
   e.g. if you import the my_ns namespace and use class1, then
   my_ns/class1.php will be searched in the path and then __autoload will be
   called with "my_ns:class1".

Requirements

• Namespace/class naming convention

Pros

• Full class name is passed to __autoload

Cons

• Performance loss (when the directories are searched, the path to the class
  file is already known before __autoload is called, so generating the full
  class name from the path, calling __autoload, only to then str_replace
  colons with slashes and including that seems unnecessary).
• When a class name exists in more than one imported namespace, the first
  one found will be passed to __autoload (no way to disambiguate).

2. Like (1), but search all the directories and pass an extra argument (or
   pass an array or object as the first argument) to __autoload indicating the
   directories where the class name was found. The first argument would be the
   class name, the second argument (or an additional key in the array) would
   contain the paths (or namespace names, whichever). The user would be
   responsible for disambiguation in case a class exists in multiple imported
   namespaces.

Requirements

• Namespace/class naming convention

Pros

• No ambiguity
• The include behavior is handled completely by the user

Cons

• In the majority of cases, a class name will not appear in more than one
  namespace, so there will be a performance loss by having to search all the
  directories in the class/include_path, even though there was a match on the
  first directory.

3. Simply pass an extra argument (or pass an array or object as the first
   argument) to __autoload containing the names of the imported namespaces of
   the calling file. __autoload can then use this array against the class name
   and perform its own lookup.

Requirements

• None

Pros

• A namespace/class naming convention is not forced
• The include behavior/lookup is handled completely by the user
• No performance loss (all that's passed to __autoload is the class name and
  an array of imported namespaces, and this is done immediately).

Cons

• IMHO, I think most users would maintain a naming convention similar to
  Java's, so the user would have to add code for something which the language
  should handle for them. This can be minimized, though, if a function is
  added to handle this common behavior. The function can be called by the
  user in __autoload and will look something like the following (of course,
  the code would be in C):

<?php
function namespace_include($className, $importNamespaces)
{
$paths = explode( PATH_SEPARATOR, get_include_path() );

foreach( $paths as $path )
{
    foreach( $importNamespaces as $ns )
    {
        $fullPath = $path . `DIRECTORY_SEPARATOR` . str_replace( ':',

DIRECTORY_SEPARATOR, $ns ) . DIRECTORY_SEPARATOR . $className . '.php';

        if( file_exists( $fullPath ) )
        {
            require_once( $fullPath );
            return true;
        }
    }
}

return false;

}
?>

I still think the namespace import behavior should be separate from the
__autoload function. Of course, this is just me. What does everyone else
think? I'd like to gather opinions on which is preferred. I will also like
to know if a separate class_path is preferred (as I have in my last patch)
or if just leaving include_path is what most prefer.

--
Jessie

I don't like this idea; it restricts the developer to this Java-like
class / directory layout. It also restricts him to name his files after
the scheme you defined (which is <classname>.php) - many use other
schemes. Shouldn't PHP let you be free in this kind of decision? I think
yes, especially, as this could also be implemented with the __autoload
function in user-space.

You already have the ability to overload __autoload or provide several
userspace __autoload functions that would be called one after another
until the first succeeds. What else do you want? Besides the fact that
i am still convinced that we should find a way to pass the full namespaced
name to __autoload instead of just the classname. If you ask me not doing
so is simply an error.

Yes, I was saying to use __autoload instead of the proposed import
magic.

Here's another one: the script

<?php
$foo= 'Foo:Bar';
import $foo;
?>>

gives me

alex@boost:~/cvs/php-namespaces# sapi/cli/php ~/tests/classes/dynamic_import.php

Parse error: parse error, unexpected T_VARIABLE, expecting
T_NAMESPACE_NAME or T_NAMESPACE in
/mnt/home/alex/tests/classes/dynamic_import.php on line 3

(IIRC Stanislav Malyshev already mentioned this in the YANP-thread
already.)

I don't see any reason to allow this. PHP is already far to dynamic (which
already prevents some speed improvements to the engine). Namespaces are a
means for working with several frameworks/libraries at a time and for
spreading/controlling responsibilities. In all those cases you definitively
won't need the above and its presents would circumvent what we'd achieve
here.

import $this is just something I'd expect PHP to be able to deal with -
but I could live without it.

Btw, if you're saying "Namespaces are for spreading/controlling
responsibilities", do you mean something like the package access level
for methods and member variables Java has? Is anyone thinking of
introducing this?

-Alex

Hello Jessie,

i am quite sure it tells you that you have a conflict with the ternary
operator. Look up the archives on the issue. There should also be an
example on the matter.

marcus

Tuesday, July 26, 2005, 2:02:56 AM, you wrote:

Alex Kiesel wrote:

Hi Jessie,

first, while your patch applied cleanly (except zend_vm_opcodes.h, which
is generated) the build broke with:
bison -y -p zend -v -d
/mnt/home/alex/cvs/php-namespaces/Zend/zend_language_parser.y -o
Zend/zend_language_parser.c
conflicts: 5 shift/reduce
/mnt/home/alex/cvs/php-namespaces/Zend/zend_language_parser.y: expected 4
shift/reduce conflicts *** Error code 1

I had to increase the expected shift/reduce conflict count to 5 to
continue the build, which then completed successfully.

I am no expert in bison or yacc, so could someone look at the patch and tell
me what, if anything, is wrong, and how to fix it?

I don't like this idea; it restricts the developer to this Java-like
class / directory layout. It also restricts him to name his files after
the scheme you defined (which is <classname>.php) - many use other
schemes. Shouldn't PHP let you be free in this kind of decision? I think
yes, especially, as this could also be implemented with the __autoload
function in user-space.

The scheme is needed in order to locate class files for the classes that
have been imported in a full namespace import. With no convention, we're
forced to call __autoload, and since the only thing that will be passed is
the class name, __autoload will have no way of knowing to what namespace
that class belongs to. With the convention, each imported namespace's
directory can be checked to see which one contains the class file.

Here's another one: the script

<?php
$foo= 'Foo:Bar';
import $foo;
?>

gives me

alex@boost:~/cvs/php-namespaces# sapi/cli/php
~/tests/classes/dynamic_import.php

Parse error: parse error, unexpected T_VARIABLE, expecting
T_NAMESPACE_NAME or T_NAMESPACE in
/mnt/home/alex/tests/classes/dynamic_import.php on line 3

(IIRC Stanislav Malyshev already mentioned this in the YANP-thread
already.)

What Stanislav and I were discussing was not this, it was the following
(variable class names), which is fully supported in the patch:

<?php
import Foo:Bar;
$name = 'Bar';
$obj = new $name();
?>>

Anyways, thanks for taking the time to try out the patch! Let me know if you
have any other ideas/suggestions.

--
Jessie

--
Best regards,
Marcus mailto:mail@marcus-boerger.de