Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
Hello Jessie, what ever you want auto-of-the-box is good. I suggest the simplest possible way as default which is we simply stay like we are doing now and only include a replacement from ':' to the current directory separator. That we would be searching for '.inc' and '.inc.php' per default in the include_path directories. marcus Tuesday, August 2, 2005, 5:17:45 PM, you wrote: Forgot to mention, since I expect the majority of users to follow the PEAR convention for their classes (basically one class per file, file is named like class, with namespace directories), then maybe a default implementation can be provided in SPL's autoload. That way, namespace imports can be used out of the box. Marcus, what do you think? Regards, Jessie Hernandez Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
Hello Michael, i suffest that pear finally takes a better approach with the arrival of namespaces then the ugly workaround of '_'. If pear doesn#t want to i suggest pear simply writes it's own __autoload(). marcus Tuesday, August 2, 2005, 6:01:18 PM, you wrote: Hi Jessie Hernandez, you wrote: Forgot to mention, since I expect the majority of users to follow the PEAR convention for their classes (basically one class per file, file is named like class, with namespace directories) With the minor but essential logical difference: $file = strtr($class, '_', '/') I don't know if you took that into account though... Regards, -- Michael - mike(@)php.net Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
Hi Marcus Boerger, you wrote: Hello Michael, i suffest that pear finally takes a better approach with the arrival of namespaces then the ugly workaround of '_'. Of course -- PEAR would benefit a lot of namespaces! -- Michael - mike(@)php.net signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
Hello Marcus, This simple change will make class imports work out of the box, which is pretty good. What won't work out of the box are namespace imports. I think we should provide this also (using the same logic as I'm using in namespace_autoload.php). Even though this will complicate the default spl_autoload function, namespace imports would work by default and will be faster than the userland code. I'll try to add the spl_autoload changes in my patch in the next few days. Also, I just looked at the php_spl.c code, is there any reason why .php is not in the list of default extensions? It'd be nice if the default extensions were .php, .inc, and .inc.php. Best regards, Jessie Marcus Boerger [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello Jessie, what ever you want auto-of-the-box is good. I suggest the simplest possible way as default which is we simply stay like we are doing now and only include a replacement from ':' to the current directory separator. That we would be searching for '.inc' and '.inc.php' per default in the include_path directories. marcus Tuesday, August 2, 2005, 5:17:45 PM, you wrote: Forgot to mention, since I expect the majority of users to follow the PEAR convention for their classes (basically one class per file, file is named like class, with namespace directories), then maybe a default implementation can be provided in SPL's autoload. That way, namespace imports can be used out of the box. Marcus, what do you think? Regards, Jessie Hernandez Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
Maybe I'm alone on this, but all my class files are named as Classname.class.php... (hint, hint) :) ... On second thought, maybe it would be interesting/useful to have some mechanism to allow a formatted string like %s.foo.php or foo.%s.php to be used by spl's autoload? Not really sure how it would be implemented... A php.ini setting ;), or from a constant or something. *shrug* dunno, just thinking out loud. Jessie Hernandez wrote: Also, I just looked at the php_spl.c code, is there any reason why .php is not in the list of default extensions? It'd be nice if the default extensions were .php, .inc, and .inc.php. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
This sounds awesome. Good job, Jessie. Keep it up!
- David
-Original Message-
From: Jessie Hernandez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 02, 2005 6:07 AM
To: internals@lists.php.net
Subject: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
Attached is the latest version of the namespace patch! It finally includes
namespace imports and it even includes anonymous namespace support. Also,
the previous bison shift/reduce conflict has been removed. Here is a
summary of its features:
- Simple imports: import ns:class1;
- Import aliases: import ns:class1 as my_alias;
- Namespace imports: import namespace ns;
- Anonymous namespaces: namespace { class file_class{} }
- Namespace-private classes: namespace ns{ private class prv_class{} }
Two new functions have also been added to support namespace imports (more
on
that below):
- get_imported_namespaces([$className])
Returns an array of imported namespaces for the current file. If a class
name is passed, and this class is currently being autoloaded (also meaning
that this function is called inside __autoload), then the list of returned
imported namespaces is based on the file that triggered the __autoload
call.
- autoload_import_class($className, $namespaceName)
Imports a class in a given namespace for the currently executing file (can
ONLY be used inside __autoload!)
Imports
---
Imports and namespace imports are handled completely by the user with the
use of the __autloload function. This means that there are no restrictions
on class file naming/directory structure. For simple imports, the class
name will be passed with its full name (including the colons, such as
ns:class1). For namespace imports, only the class name will be called.
Since the user needs to determine which namespace (or namespaces) a class
belongs to, the get_imported_namespaces function is provided to check
the
imported namespaces for the currently-executing file. Once the user is
satisfied with a match, he/she needs to perform an import for this
class,
but this needs to be done on the executing file, not the file where
__autoload is defined. For this reason, the autoload_import_class function
is provided. A sample usage of both these functions is at
tests/classes/namespace_autoload.php.
Namespace-private classes
-
Classes marked as private from within a namespace can only be used by
classes defined in the same namespace.
Anonymous namespaces
Classes defined inside anonymous namespaces can only be used within the
file
that declared the anonymous namespace.
I believe the attached patch solves the issues that were presented long
ago
for namespaces. Referring to the post by Daniel Cogwill at
http://www.zend.com/lists/engine2/200304/msg00164.html, the following are
my answers to the problems he found at the time:
1) import-all silently hides local names.
A: If a global class is defined with the same name as a class in a
namespace, and the namespace class has been imported in the same script,
the global class takes precedence. The namespace class can still be used
by
using its full name, i.e. namespace_name:class_name.
2) Interestingly (and I assume this is simply a bug), functions and
classes
behave differently wrt to import-all and duplicate definitions.
A: Irrelevant in this patch.
3) There is no way to hide names from import (i.e. make a name
non-exportable). This is a fundamental namespace feature, and there is
already an appropriate keyword (private).
A: Namespace-private classes are supported, using the private keyword.
4) The semantic meaning of successive imports depends on their relative
ordering.
A: The engine does not attempt to determine which class is included, the
user decides the most appropriate behavior inside __autoload.
5) The most egregious issue is that an import in an included file affects
the scope of the including file.
A: Imports in this patch only affect the file they are in.
Since I could not find a way to add the tests/classes/namespace directory
and subdirectories, I zipped them separately, as before.
Let me know if you have any questions on the attached patch.
Best regards,
Jessie Hernandez
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
Jessie Hernandez wrote:
Attached is the latest version of the namespace patch! It finally includes
namespace imports and it even includes anonymous namespace support. Also,
the previous bison shift/reduce conflict has been removed. Here is a
summary of its features:
- Simple imports: import ns:class1;
- Import aliases: import ns:class1 as my_alias;
- Namespace imports: import namespace ns;
- Anonymous namespaces: namespace { class file_class{} }
- Namespace-private classes: namespace ns{ private class prv_class{} }
Two new functions have also been added to support namespace imports (more on
that below):
- get_imported_namespaces([$className])
Returns an array of imported namespaces for the current file. If a class
name is passed, and this class is currently being autoloaded (also meaning
that this function is called inside __autoload), then the list of returned
imported namespaces is based on the file that triggered the __autoload
call.
so, if I understand correctly, if your __autoload is defined in a
different file(file1) from where the import was
called(file2), then get_imported_namespaces() returns the namespace
imports for file1.
get_imported_namespaces($className) would return for file2, and outside
of the __autoload function,
get_imported_namespaces($className) would return the namespaces for
file1. That seems like
complicated semantics. Is there some way this could be simplified? Maybe
there should be two functions,
one that returns namespaces for file2 and is incorrect(throws an error)
to call from anywhere other than
__autoload(), and one that returns namespaces for file2.
- autoload_import_class($className, $namespaceName)
Imports a class in a given namespace for the currently executing file (can
ONLY be used inside __autoload!)
Imports
---
Imports and namespace imports are handled completely by the user with the
use of the __autloload function. This means that there are no restrictions
on class file naming/directory structure. For simple imports, the class
name will be passed with its full name (including the colons, such as
ns:class1). For namespace imports, only the class name will be called.
Since the user needs to determine which namespace (or namespaces) a class
belongs to, the get_imported_namespaces function is provided to check the
imported namespaces for the currently-executing file. Once the user is
satisfied with a match, he/she needs to perform an import for this class,
This seems like it would be slow, as the user might have many
namespaces(directories) to search for matching
files. This would of course be up to the user. And it doesn't bother me
that a full namespace import
may not be as fast as a more specific import. In development it might be
convenient, but at some point, it's not
that big a deal to specify the classes you use.
but this needs to be done on the executing file, not the file where
__autoload is defined. For this reason, the autoload_import_class function
is provided. A sample usage of both these functions is at
tests/classes/namespace_autoload.php.
I like the option of having namespaces, and from the description this
seems to be a light method of doing it. It does
require some effort from the user. It seems that for most cases
__autoload will be the same every time, maybe with
different paths or file naming conventions.
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
Forgot to mention, since I expect the majority of users to follow the PEAR convention for their classes (basically one class per file, file is named like class, with namespace directories), then maybe a default implementation can be provided in SPL's autoload. That way, namespace imports can be used out of the box. Marcus, what do you think? Regards, Jessie Hernandez -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
Hi Jessie Hernandez, you wrote: Forgot to mention, since I expect the majority of users to follow the PEAR convention for their classes (basically one class per file, file is named like class, with namespace directories) With the minor but essential logical difference: $file = strtr($class, '_', '/') I don't know if you took that into account though... Regards, -- Michael - mike(@)php.net signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
Hi Michael, Yes, I am aware of this. Underscores were used due to the lack of namespaces. For user classes which use namespaces (and in the case where some PEAR classes get modified to be under namespaces), the colon would be used as the separator, and this would get replaced by the slash to form the file path. -- Jessie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
FYI, I haven't had a chance to look at this patch yet (nor a lot of the
emails on the subject). After PHP 5.1 goes RC and we start our Unicode
work, I should have time to look into it. Interesting to see if it
addresses the issues we had in the past. I think some of them weren't
solvable although if this only addresses classes it might have. One note,
we need to make sure we don't complicate the language too much... But
anyway, hopefully next week or so I'll have more constructive feedback.
At 12:07 AM 8/2/2005 -0400, Jessie Hernandez wrote:
Attached is the latest version of the namespace patch! It finally includes
namespace imports and it even includes anonymous namespace support. Also,
the previous bison shift/reduce conflict has been removed. Here is a
summary of its features:
- Simple imports: import ns:class1;
- Import aliases: import ns:class1 as my_alias;
- Namespace imports: import namespace ns;
- Anonymous namespaces: namespace { class file_class{} }
- Namespace-private classes: namespace ns{ private class prv_class{} }
Two new functions have also been added to support namespace imports (more on
that below):
- get_imported_namespaces([$className])
Returns an array of imported namespaces for the current file. If a class
name is passed, and this class is currently being autoloaded (also meaning
that this function is called inside __autoload), then the list of returned
imported namespaces is based on the file that triggered the __autoload
call.
- autoload_import_class($className, $namespaceName)
Imports a class in a given namespace for the currently executing file (can
ONLY be used inside __autoload!)
Imports
---
Imports and namespace imports are handled completely by the user with the
use of the __autloload function. This means that there are no restrictions
on class file naming/directory structure. For simple imports, the class
name will be passed with its full name (including the colons, such as
ns:class1). For namespace imports, only the class name will be called.
Since the user needs to determine which namespace (or namespaces) a class
belongs to, the get_imported_namespaces function is provided to check the
imported namespaces for the currently-executing file. Once the user is
satisfied with a match, he/she needs to perform an import for this class,
but this needs to be done on the executing file, not the file where
__autoload is defined. For this reason, the autoload_import_class function
is provided. A sample usage of both these functions is at
tests/classes/namespace_autoload.php.
Namespace-private classes
-
Classes marked as private from within a namespace can only be used by
classes defined in the same namespace.
Anonymous namespaces
Classes defined inside anonymous namespaces can only be used within the file
that declared the anonymous namespace.
I believe the attached patch solves the issues that were presented long ago
for namespaces. Referring to the post by Daniel Cogwill at
http://www.zend.com/lists/engine2/200304/msg00164.html, the following are
my answers to the problems he found at the time:
1) import-all silently hides local names.
A: If a global class is defined with the same name as a class in a
namespace, and the namespace class has been imported in the same script,
the global class takes precedence. The namespace class can still be used by
using its full name, i.e. namespace_name:class_name.
2) Interestingly (and I assume this is simply a bug), functions and classes
behave differently wrt to import-all and duplicate definitions.
A: Irrelevant in this patch.
3) There is no way to hide names from import (i.e. make a name
non-exportable). This is a fundamental namespace feature, and there is
already an appropriate keyword (private).
A: Namespace-private classes are supported, using the private keyword.
4) The semantic meaning of successive imports depends on their relative
ordering.
A: The engine does not attempt to determine which class is included, the
user decides the most appropriate behavior inside __autoload.
5) The most egregious issue is that an import in an included file affects
the scope of the including file.
A: Imports in this patch only affect the file they are in.
Since I could not find a way to add the tests/classes/namespace directory
and subdirectories, I zipped them separately, as before.
Let me know if you have any questions on the attached patch.
Best regards,
Jessie Hernandez
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
