Same as before, with the following changes:
- Fixed memory leaks.
- Added NAMESPACE constant.
Regards,
Jessie Hernandez
I was made aware of the fact that the patch wasn't compiling in ZTS mode, so
I fixed this in the attached patch (I still have not gotten a chance to
test under Windows, but it does work on Linux, both in ZTS and non-ZTS
mode). Other than that, there are no other changes.
Regards,
Jessie
Classes that had uppercase letters were not being handled properly in
namespace imports. The attached patch has this fix (thanks Maxx!). Also,
the attached patch includes the default behavior of resolving
simple-imported class names to their file paths (ns:class1 being looked up
as ns/class1(.inc or .inc.php).
I have a couple of questions, though:
-
I asked this before, but it wasn't answered: is there any reason why .php
is not a default extension for spl_autoload? -
Right now, you have to use the autoload_import_class function for
namespace imports so that the class names are properly found. This function
can be eliminated if there was a way for me to get the last inserted
element in the class_table. Can I just simply call
zend_hash_internal_pointer_end_ex on class_table and get that end element,
assuming that this was the last element that was inserted? Or is the order
in which items are inserted into a hashtable undefined?
Regards,
Jessie
Hello Jessie,
Tuesday, August 9, 2005, 4:36:41 AM, you wrote:
Classes that had uppercase letters were not being handled properly in
namespace imports. The attached patch has this fix (thanks Maxx!). Also,
the attached patch includes the default behavior of resolving
simple-imported class names to their file paths (ns:class1 being looked up
as ns/class1(.inc or .inc.php).
I have a couple of questions, though:
- I asked this before, but it wasn't answered: is there any reason why .php
is not a default extension for spl_autoload?
PEAR uses .inc.php and i as well as all i have spoken too like .inc better
than .php becuase it distinguishes include files from normal script files.
If now you like .php better it is pretty easy to overcome this matter by
just changing the defaults. That's why it is so flexible.
Best regards,
Marcus
Hi Marcus Boerger, you wrote:
Hello Jessie,
Tuesday, August 9, 2005, 4:36:41 AM, you wrote:
- I asked this before, but it wasn't answered: is there any reason why .php
is not a default extension for spl_autoload?PEAR uses .inc.php and i as well as all i have spoken too like .inc better
than .php becuase it distinguishes include files from normal script files.
Huh? I pretty much doubt that. PEAR disallows anything than .php IIRC.
I don't mind though if it's configurable...
Cheers,
Michael - < mike(@)php.net
I finally got a chance to test under Windows today, and there was a
variable that was not being initialized under ZTS mode that was causing
problems in Windows. The attached patch is correctly initializing it. Also,
the namespace_anonymous.php file was missing from the patch, which the
attached now has. The files used by the tests have not changed, so
tests.tar.gz from the first post in this thread can still be used.
Regards,
Jessie
Jessie Hernandez wrote:
Classes that had uppercase letters were not being handled properly in
namespace imports. The attached patch has this fix (thanks Maxx!). Also,
the attached patch includes the default behavior of resolving
simple-imported class names to their file paths (ns:class1 being looked up
as ns/class1(.inc or .inc.php).I have a couple of questions, though:
I asked this before, but it wasn't answered: is there any reason why
.php is not a default extension for spl_autoload?Right now, you have to use the autoload_import_class function for
namespace imports so that the class names are properly found. This
function can be eliminated if there was a way for me to get the last
inserted element in the class_table. Can I just simply call
zend_hash_internal_pointer_end_ex on class_table and get that end element,
assuming that this was the last element that was inserted? Or is the order
in which items are inserted into a hashtable undefined?Regards,
Jessie