Hello Weyert,
"Weyert de Boer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello,
>
> May I make some sort of suggestion, without having a closer look at the
> internal working of PHP, the below is jsut one big day dream for me.
>
> My idea is to wrap namespaces by default, for example when you aren't
> using any namespace-keywords into your code, the parser will add these
> accordingly to a nameless namespace (i.e.: namespace { }) this means
> that you can access a class just as normal via MyClassName() etc.
This already works in the current patch. If the class does not reside in a
namespace, then it belongs to the "global" namespace and it is left
unprefixed in the class_table. What you describe as "nameless namespace" is
what the global namespace is. Your syntax for "nameless namespaces" also
means something different in C++, which are "anonymous namespaces".
Anonymous namespaces can be used to declare classes in one file for use only
within the file in which it was declared (if the class is referenced from
another file, an error will be generated). I can easily add this feature in
my implementation. Does anyone find this feature useful?
> But when you are using namespaces i..e
>
> namespace innerfuse {
>
> namespace RepositoryEngine {
>
> final interface IRepistory {
> blabla
> }
>
> class Repository implements IRepository {
> // blabla
> }
> }
> }
>
> You can now access those stuff via innerfuse.*;
> innerfuse.RepositoryEngine.* or the exact "path" to the class or
> interface innerfuse.RepositoryEngine.*. Now probably will ask but how do
> you want to lookup the class files? Well, I think this can be done
> through by defining a classPath. I won't mind putting my files which use
> namespaces in a specified directory, as long this can be altered i.e.
> set_classes_path( 'blabla' ) or through comments magic.
>
Since __autoload will now be used, the class_path .ini variable seems
unnecessary.
> Now because each PHP file needs to be parsed anyway before it can be
> used, i.e. transformation to opcode. You can of course just get all the
> php files, from the classes path recursively. Keep a list of all
> namespaces found and classes which belong to these in a hierarchy, for
> example you could give each class a unique number/name internally.
> After all the available classes and namespaces are available, or when a
> namespace confliction is encountered, a fatal error should be raised.
> You now got a nice tree of available classes and to which namespaces it
> belongs, with a reference to the file where the class definition is
> available. Now you won't need this file anymore, though. It should now
> be possible to convert it into the opcode.
>
Recursively reading/parsing each file under the class_path would be VERY
slow to say the least. Caching would be an absolute requirement. Regarding
this...
> Anyways some sort of caching is always nice, for example a hidden file
> myphpfile.php.cache which includes a cached version of the php file in
> opcode, which same some parsing time :+
>
Let's say all the classes have been searched and cached in the .cache file,
and that later I add a new class to the class_path and create a new script
that uses this new class. How will I know that a new file has been added to
a directory under the class_path? I would have to recursively go through the
directories again to see if the new class is defined there. Also, if I
change the name of a class in a file that has already been cached in the
.cache file, I will not be notified of this change either.
I also see locking issues with this approach. If multiple requests are being
performed and the .cache file does not exist yet, the other requests somehow
have to be notified to wait until the first request goes through all of the
files in the class_path and creates the .cache file. This is another big
performance issue.
--
Jessie
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
