The attached patch includes variable class name support (test file has also
been updated). To clarify for the benefit of others, this means that the
code below will work. Note that imports are still done on "file-level"
scope, even at runtime, so you can only create objects using variable
import cl
Stanislav,
Correct, in fact, I began to work on this yesterday. My approach will be to
translate whatever's possible at compile-time, as I'm doing now, and saving
the import alias info for what's needed at runtime, such as in the case of
variable class names. This hashtable will also be needed for
JH>>- Classes may not contain colons (no change here), BUT class name references
JH>>CAN contain colons (this is KEY!).
JH>>- All imports are done at compile time.
JH>>- Imports only affect the current file (yes, this has been done!)
The problem here is that once you have somewhat developed packag
JH>>is a znode, and what is assigned to the opcode is "opline->op2 =
JH>>*class_name". This function is changed to check the import hashtable, and if
JH>>a match is found, then the znode string value is updated to contain the full
JH>>class name! Here's some pseudocode:
This of course won't work w
David,
You are right, classes that don't use self might break, although there might
be a solution for this: when a class declaration is started, immediately
"import" the class. This will fix the problem, but I don't really think
it's necessary. After all, if you're using an new feature as namespac
One more thing, here's an example of how things go in the enterprise and
where namespaces make or break PHP being used.
Every now and then, someone says "Let's merge projects A and B", and
those projects could be in different parts of the world, each having 10s
if not 100s of developers, and very
I think we're trying to boil the ocean here, and in doing so failing to
see both the problems that need to be solved, and the possible
solutions. I'd like to break things down a little bit here to address
what the real problem is with a lack of namespaces in PHP.
In my eyes, there are really only
JH>>With the above scenario, nothing will be affected if there is an
JH>>opcode cache or not. The only situation I can think of where an opcode
JH>>cache can affect this is when the script DYNAMICALLY creates classes
JH>>from the imported namespace. Maybe there's other situations, but I
JH>>can
Did you make sure to real all the past threads on the issue?
There are a variety of problems which arise with such a namespaces
implementation, including ambiguity, problems with multiple symbol table
lookups, dynamic variable creation, cross-file dependencies. I believe this
solution suffers f
Could you elaborate on this? Let's say we have the following situation:
- a.php does a full namespace import of "my_namespace".
- The /my_namespace directory has two files (classes),
class1.php and class2.php.
- a.php has the following code:
- After a.php is first run, a new file, class3.php, is
JH>>// 1) "my_namespace:class1" is added to the import hashtable.
JH>>// 2) The opcode for
JH>>"require_once('/usr/local/php-classes/my_namespace/class1.php')" is
JH>>generated.
JH>>// 3) "my_namespace:class2" is added to the import hashtable.
JH>>// 4) The opcode for
JH>>"require_once('/usr/local/
I'm still debating whether importing all symbols from a namespace is a good
idea or not (I sometimes use Java at work, and I never import a full package
myself, and this is not recommended anyways). But, if it were to be
implemented, then below is how I would approach it. The following would be
req
Actually, this will work! In the "class_name_reference" rule, the
"zend_do_fetch_class" function is called. Inside this function, class_name
is a znode, and what is assigned to the opcode is "opline->op2 =
*class_name". This function is changed to check the import hashtable, and if
a match is found
at compile time? this means u cannot import * (all) symbols from a namespace
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[...]
> - All imports are done at compile time.
So:
== Object.php ==
== script.php ==
...will not work. You'll need an opcode for this.
- Timm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
lists.php.net
> Subject: RE: [PHP-DEV] YANP (Yet Another Namespace Proposal)
>
> Sounds sweet. However, I already found a problem there, it has to do with
> aliasing. Lots of code (libraries) will, even inside the same class, use
> the
> class name for method calls instead of th
://article.gmane.org/gmane.comp.php.devel/29492, might be
of help, dunno
> -Original Message-
> From: Jessie Hernandez [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 07, 2005 2:44 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] YANP (Yet Another Namespace Proposal)
I have locally made changes to support namespaces, with minimal impact to
the Zend Engine (I based my changes on PHP 5.1.0b2). I have gone through
the archives and read the previous discussions about namespaces and the
outstanding issues, and to the best of my knowledge, I think my changes
solve th
18 matches
Mail list logo
