[PHP-DEV] Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorderissues)
Stanislav Malyshev wrote:
> Hi!
>
>> The caching is at runtime. Basically, it's in executor_globals, and so
>> is not linked to any opcode array (I couldn't figure out any other
>> globally accessible storage location). It works like an associative
>> array. If file X.php loads XMLReader in namespace namespacename, it
>> creates this entry:
>>
>> array(
>> 'X.php\0namespacename::XMLReader' => {class entry for XMLReader}
>> );
>
> I though a bit about that patch, and I see following problems with it:
>
> 1. If you do not use autoloading, you still can get different
> resolution, e.g.:
>
> namespace foo;
> $a = new XMLReader;
>
> resolves to ::XMLReader and cached for this file. But suppose some other
> file, somewhere, loaded foo::XMLReader prior to that. Then the same code
> here would resolve now to foo::XMLReader as before, right?
> Isn't it the same scenario you complained about? If so this patch does
> not solve this for 100% of cases, unless I misunderstand how the patch
> works.
>
> 2. While the caching indeed helps per-file, typical OO application
> contains dozens of files, and each file may use dozens of internal
> classes (my install has 100+ internal classes). Meaning, there is still
> potential for hundreds of non-cacheable exhaustive autoload searches.
> This is not a good scenario.
Your first point is correct, and the second is interesting, but does not
quite match reality. I whipped up a script to count the number of
internal vs. user classes in a project, it's at
http://pear.php.net/~greg/detect_classes.phps
I ran it on PEAR2, which is a pre-namespace project at the moment, and
came up with these stats:
Internal classes: 239
User classes: 768
in 171 files
I ran the same script over PEAR, and got:
Internal classes: 110
User classes: 2027
in 231 files
Now, you may argue that these are atypical OO applications, so I also
ran the script over Zend Framework 1.5, with these results:
Internal classes: 950
User classes: 16167
in 1821 files
In other words, there is simply no comparison. Userspace class usage
outnumbers internal class usage by an order of magnitude in typical OO
PHP code.
PEAR2 uses an average of 2 internal classes per file, and 7 userspace
classes. PEAR uses an average of 0.5 internal classes per file, and 8
userspace classes per file. Zend Framework uses an average of 0.5
internal classes per file and ~9 userspace classes per file. Thus, if I
had to choose between defaulting to current namespace (as you suggested)
and to internal classes, the choice is easy. I would choose current
namespace because there would be far fewer use statements, and the
behavior is deterministic.
The script is at:
http://pear.php.net/~greg/detect_classes.phps
run with "php detect_classes.php /path/to/files"
Oh, and the script is one of the few cases where there are 3 internal
classes used and only 1 userspace class :).
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
Hi,
I just figured a problem related to this.
We have multiple namespaces per file so we can merge multiple files
together. We have no way to break out to global space after a namespace, and
even with this patch, no *code* can exist before a namespace.
So this means we can only merge files with namespaces in them.
Regards,
Stan Vassilev
Hi,
This is a simple patch that allows files like this:
main.php:
template example
to work without parse error.
Greg
P.S. this is the last outstanding namespace issue that I'm aware of
aside from the bracket wars, which is 100% philosophical, all the issues
fixed by my patches are functional problems in namespaces.
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.85
diff -u -u -r1.647.2.27.2.41.2.85 zend_compile.c
--- Zend/zend_compile.c 29 Aug 2008 10:17:08 - 1.647.2.27.2.41.2.85
+++ Zend/zend_compile.c 12 Sep 2008 19:07:42 -
@@ -504,13 +504,17 @@
}
-void zend_do_echo(const znode *arg TSRMLS_DC)
+void zend_do_echo(const znode *arg, int is_html TSRMLS_DC)
{
zend_op *opline = get_next_op(CG(active_op_array) TSRMLS_CC);
opline->opcode = ZEND_ECHO;
opline->op1 = *arg;
- SET_UNUSED(opline->op2);
+ if (is_html) {
+ opline->op2.op_type = IS_CONST; /* tell zend_do_namespace that
INLINE_HTML is OK */
+ } else {
+ SET_UNUSED(opline->op2);
+ }
}
void zend_do_abstract_method(const znode *function_name, znode *modifiers,
const znode *body TSRMLS_DC)
@@ -5040,10 +5044,11 @@
char *lcname;
if (CG(active_op_array)->last > 0) {
- /* ignore ZEND_EXT_STMT and ZEND_TICKS */
+ /* ignore ZEND_EXT_STMT and ZEND_TICKS and T_INLINE_HTML */
int num = CG(active_op_array)->last;
while (num > 0 &&
(CG(active_op_array)->opcodes[num-1].opcode == ZEND_EXT_STMT ||
+ (CG(active_op_array)->opcodes[num-1].opcode == ZEND_ECHO &&
CG(active_op_array)->opcodes[num-1].op2.op_type == IS_CONST) ||
CG(active_op_array)->opcodes[num-1].opcode == ZEND_TICKS)) {
--num;
}
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.33
diff -u -u -r1.316.2.8.2.12.2.33 zend_compile.h
--- Zend/zend_compile.h 29 Aug 2008 18:12:47 - 1.316.2.8.2.12.2.33
+++ Zend/zend_compile.h 12 Sep 2008 19:07:42 -
@@ -385,7 +385,7 @@
void fetch_string_offset(znode *result, const znode *parent, const znode
*offset TSRMLS_DC);
void zend_do_fetch_static_member(znode *result, znode *class_znode
TSRMLS_DC);
void zend_do_print(znode *result, const znode *arg TSRMLS_DC);
-void zend_do_echo(const znode *arg TSRMLS_DC);
+void zend_do_echo(const znode *arg, int is_html TSRMLS_DC);
typedef int (*unary_op_type)(zval *, zval * TSRMLS_DC);
typedef int (*binary_op_type)(zval *, zval *, zval * TSRMLS_DC);
ZEND_API unary_op_type get_unary_op(int opcode);
Index: Zend/zend_language_parser.y
===
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.160.2.4.2.8.2.26
diff -u -u -r1.160.2.4.2.8.2.26 zend_language_parser.y
--- Zend/zend_language_parser.y 29 Aug 2008 17:54:29 -
1.160.2.4.2.8.2.26
+++ Zend/zend_language_parser.y 12 Sep 2008 19:07:42 -
@@ -236,7 +236,7 @@
| T_GLOBAL global_var_list ';'
| T_STATIC static_var_list ';'
| T_ECHO echo_expr_list ';'
- | T_INLINE_HTML { zend_do_echo(&$1 TSRMLS_CC); }
+ | T_INLINE_HTML { zend_do_echo(&$1, 1 TSRMLS_CC); }
| expr ';' { zend_do_free(&$1 TSRMLS_CC); }
| T_UNSET '(' unset_variables ')' ';'
| T_FOREACH '(' variable T_AS
@@ -556,8 +556,8 @@
;
echo_expr_list:
- echo_expr_list ',' expr { zend_do_echo(&$3 TSRMLS_CC); }
- | expr { zend_do_echo(&$1 TSRMLS_CC); }
+ echo_expr_list ',' expr { zend_do_echo(&$3, 0 TSRMLS_CC); }
+ | expr { zend_do_echo(&$1, 0 TSRMLS_CC); }
;
Index: Zend/tests/ns_076.phpt
===
RCS file: Zend/tests/ns_076.phpt
diff -N Zend/tests/ns_076.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/ns_076.phpt 12 Sep 2008 19:07:42 -
@@ -0,0 +1,26 @@
+--TEST--
+076: T_INLINE_HTML prior to namespace declaration
+--FILE--
+hi there
+
+===DONE===
+--EXPECT--
+hi there
+string(3) "foo"
+string(0) ""
+string(3) "foo"
+===DONE===
Index: Zend/tests/ns_077.phpt
===
RCS file: Zend/tests/ns_077.phpt
diff -N Zend/tests/ns_077.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/ns_077.phpt 12 Sep 2008 19:07:42 -
@@ -0,0 +1,21 @@
+--TEST--
+076: T_ECHO prior to namespace declaration
+--FILE--
+
+===DONE===
+--EXPECTF--
+Fatal error: Namespace declaration statement has to be the very first
statement in the script in %sns_077.php on line %d
\ No newline
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
Hi,
I'm in favor of this patch for simple reason that the "nothing before the
first namespace" limitation is more of a WTF than a sound design prevented
to limit an actual problem.
We have multiple namespaces per file, so having some of the file in the
global namespace (i.e. == no namespace) is perfectly natural in that setup.
In fact, I'd argue that we need a way to break out to global namespace
*after* a namespace too.
Something that would be naturally solved by {} but since this is
discarded... (but you see how it's not purely phylosophical issues either).
Regards,
Stan Vassilev
Hi,
This is a simple patch that allows files like this:
main.php:
template example
to work without parse error.
Greg
P.S. this is the last outstanding namespace issue that I'm aware of
aside from the bracket wars, which is 100% philosophical, all the issues
fixed by my patches are functional problems in namespaces.
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.85
diff -u -u -r1.647.2.27.2.41.2.85 zend_compile.c
--- Zend/zend_compile.c 29 Aug 2008 10:17:08 - 1.647.2.27.2.41.2.85
+++ Zend/zend_compile.c 12 Sep 2008 19:07:42 -
@@ -504,13 +504,17 @@
}
-void zend_do_echo(const znode *arg TSRMLS_DC)
+void zend_do_echo(const znode *arg, int is_html TSRMLS_DC)
{
zend_op *opline = get_next_op(CG(active_op_array) TSRMLS_CC);
opline->opcode = ZEND_ECHO;
opline->op1 = *arg;
- SET_UNUSED(opline->op2);
+ if (is_html) {
+ opline->op2.op_type = IS_CONST; /* tell zend_do_namespace that
INLINE_HTML is OK */
+ } else {
+ SET_UNUSED(opline->op2);
+ }
}
void zend_do_abstract_method(const znode *function_name, znode *modifiers,
const znode *body TSRMLS_DC)
@@ -5040,10 +5044,11 @@
char *lcname;
if (CG(active_op_array)->last > 0) {
- /* ignore ZEND_EXT_STMT and ZEND_TICKS */
+ /* ignore ZEND_EXT_STMT and ZEND_TICKS and T_INLINE_HTML */
int num = CG(active_op_array)->last;
while (num > 0 &&
(CG(active_op_array)->opcodes[num-1].opcode == ZEND_EXT_STMT ||
+ (CG(active_op_array)->opcodes[num-1].opcode == ZEND_ECHO &&
CG(active_op_array)->opcodes[num-1].op2.op_type == IS_CONST) ||
CG(active_op_array)->opcodes[num-1].opcode == ZEND_TICKS)) {
--num;
}
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.33
diff -u -u -r1.316.2.8.2.12.2.33 zend_compile.h
--- Zend/zend_compile.h 29 Aug 2008 18:12:47 - 1.316.2.8.2.12.2.33
+++ Zend/zend_compile.h 12 Sep 2008 19:07:42 -
@@ -385,7 +385,7 @@
void fetch_string_offset(znode *result, const znode *parent, const znode
*offset TSRMLS_DC);
void zend_do_fetch_static_member(znode *result, znode *class_znode
TSRMLS_DC);
void zend_do_print(znode *result, const znode *arg TSRMLS_DC);
-void zend_do_echo(const znode *arg TSRMLS_DC);
+void zend_do_echo(const znode *arg, int is_html TSRMLS_DC);
typedef int (*unary_op_type)(zval *, zval * TSRMLS_DC);
typedef int (*binary_op_type)(zval *, zval *, zval * TSRMLS_DC);
ZEND_API unary_op_type get_unary_op(int opcode);
Index: Zend/zend_language_parser.y
===
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.160.2.4.2.8.2.26
diff -u -u -r1.160.2.4.2.8.2.26 zend_language_parser.y
--- Zend/zend_language_parser.y 29 Aug 2008 17:54:29 -
1.160.2.4.2.8.2.26
+++ Zend/zend_language_parser.y 12 Sep 2008 19:07:42 -
@@ -236,7 +236,7 @@
| T_GLOBAL global_var_list ';'
| T_STATIC static_var_list ';'
| T_ECHO echo_expr_list ';'
- | T_INLINE_HTML { zend_do_echo(&$1 TSRMLS_CC); }
+ | T_INLINE_HTML { zend_do_echo(&$1, 1 TSRMLS_CC); }
| expr ';' { zend_do_free(&$1 TSRMLS_CC); }
| T_UNSET '(' unset_variables ')' ';'
| T_FOREACH '(' variable T_AS
@@ -556,8 +556,8 @@
;
echo_expr_list:
- echo_expr_list ',' expr { zend_do_echo(&$3 TSRMLS_CC); }
- | expr { zend_do_echo(&$1 TSRMLS_CC); }
+ echo_expr_list ',' expr { zend_do_echo(&$3, 0 TSRMLS_CC); }
+ | expr { zend_do_echo(&$1, 0 TSRMLS_CC); }
;
Index: Zend/tests/ns_076.phpt
===
RCS file: Zend/tests/ns_076.phpt
diff -N Zend/tests/ns_076.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/ns_076.phpt 12 Sep 2008 19:07:42 -
@@ -0,0 +1,26 @@
+--TEST--
+076: T_INLINE_HTML prior to namespace declaration
+--FILE--
+hi there
+
+===DONE===
+--EXPECT--
+hi there
+string(3) "foo"
+string(0) ""
+string(3) "foo"
+===DONE===
Index: Zend/tests/ns_077.phpt
===
RCS file: Zend/tests/ns_077.phpt
diff -N Zend/tests/ns_077.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/ns_077.phpt 1
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
Hi, On Fri, 2008-09-12 at 14:11 -0500, Greg Beaver wrote: > This is a simple patch that allows files like this: > > main.php: > > [...] > namespace my::template; > // stuff > ?> I'd prefer: main.php: looks cleaner imo. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Scoping of "use" statements and a strategy for 5.3/6.0 release of namespace
Stan Vassilev | FM wrote:
Hi,
Multiple namespaces per file were introduced to allow certain workflows in PEAR
and frameworks like Symphony which can combine multiple classes and namespaces
in a single package.
They work like this:
namespace X;
...
namespace Y;
...
The problem is, no one thought of scoping "use" statements, so now those merged files
share their "use" imports, thus breaking all the code where collisions occur.
Also we have the problems with name resolution of internal vs user classes and
autoloaders, discussed here.
And we also have the non-intuitive differentiation between resolving
functions/classes/constant which will most likely lead people to believe
functions/constants aren't supported in any way in namespaces (if they try, and
it doesn't work, they won't try second time).
Which leads me to the following proposal:
For PHP 5.3 we introduce namespaces with a very limited "safe" set of barebones
features, that we won't regret later for releasing and having to modify in a non-BC way.
It'll let people start porting their code and be ready for the full featureset later on,
which will be a proper superset of the 5.3 release:
1) We disable support for multiple namespaces per file as it is, as it can't be used
without ability to scope "use" statements as well.
2) We remove the statement "use" (regarding namespaces, not regarding
closures), until we get more feedback from the community on the exact preferred
resolution algorithms, and more thought is put to this.
For PHP 5.4 or 6:
1) Introduce file-level "use" statements with same syntax as now, but modified resolution
rules based on further discussion and feedback. And if someone is about to say "we had plenty
of discussion", well it's apparent we didn't have enough given all the problems facing
namespaces right now, or maybe not enough of the constructive type of discussion.
2) Introduce ability to scope "use" and "namespace" statements with curly
brackets, so that multiple files can be safely merged without changing intent (all file-level
namespace can be converted with curly brackets, and the existing curly bracket ones don't need to
be converted), example:
namespace X {
use Y as Z {
...
}
}
namespace Y {
use X as Z {
...
}
}
Waiting for your feedback...
Regards,
Stan Vassilev
Again, some more 2 cents from me.
I'm not sure if this has already been decided but I agree with multiple
namespaces per file. Just seems like a good practice for large
frameworks. And I'm leaning towards +1 on NON-brackets for namespaces.
With multiple namespace declarations in one file the way it is now,
brackets seem un-needed.
As far as the scope of "use" in a multi-namespace file:
Considering that in a multi-namespace file, a namespace declaration ends
the previous namespace and begins the new one. Can the scope of the
"use" statement be whatever namespace declaration it is in? Ex:
There are a couple benefits with this way:
1. If multiple namespaces have the exact same use statements, they won't
conflict. Because the scope of use only applies the current namespace
declaration.
2. Merging multiple files is easier. Before the files are merged, the
developer would probably be testing their framework. This means that the
separate files have use statements in each one. When merging them all
together, the use statements won't conflict.
I agree that if use does not have a scope, it would become confusing. If
there wasn't, what would happen when there are two exact same use
statements. Or, if use statements point to different namespaces but have
the same name.
Another question when merging multiple files, is it ok to declare the
same namespace multiple times? If I were to merge files, I would just
append them all to one file.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
David Coallier wrote: 2008/9/12 Greg Beaver <[EMAIL PROTECTED]>: Hi, This is a simple patch that allows files like this: main.php: template example Is it me or this doesn't look really clean? I have a clear idea that namespaces are there to add an extra structural layer to the code and not to be randomly used in some HTML/PHP/Javascript mixing. Since the current namespace implementation doesn't want to have multiple namespaces per file, I think we should restrict a namespace per file to... a namespace per file, and nothing else. I can't imagine taking over someone's code who had declared a namespace under is footer template. Perhaps I am missing something but that would be bloody ugly in the end :) Since you're looking for input from everyone, I'll throw my 2 cents in. I agree that this should not be allowed. Even with just a new line or space, PHP developers should learn that that is not a good practice. My feelings for namespaces is that it's for frameworks and such. I would be USING [use ...] inside a PHP/XHTML/JS type of file, not declaring a namespace. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Please don't start 10 threads a day about the Namespace support
hi all, It is much appreciated to finally some real discussions about NS support as well as new patches. However it would be even better if the discussions are kept in one thread or if complex problems are explained in the wiki and updated there. It will be then much more easier to follow this topic without using aspirine :) Thanks for your work and understanding, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
Hi! the issue is without the patch, even an empty space or a newline at the start of a file will cause a fatal error That's good. There should be no unaccounted newlines or empty spaces in PHP code. I had not once things break because somebody left whitespace floating around in some script and it broke HTML (or yet more fun, ended up in some image or PDF). -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
Marcus Boerger wrote: > Hello Greg, > > please don't OK. Nice working with you Marcus, this is high class stuff. I'm glad to see the work I'm doing is taken so seriously. Bye for now, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
Lucas Stephanou wrote: > My first msg in this list > > And I agree with you David. > > Mix html and namespace is very very ugly. > > > > 2008/9/12 David Coallier <[EMAIL PROTECTED]>: >> 2008/9/12 Greg Beaver <[EMAIL PROTECTED]>: >>> Hi, >>> >>> This is a simple patch that allows files like this: >>> >>> main.php: >>> >>> >>> >>> template example >>> >>> >>> >>> >> namespace my::template; >>> // stuff >>> ?> >>> >>> >> Is it me or this doesn't look really clean? I have a clear idea that >> namespaces are there to add an extra structural layer to the code and >> not to be randomly used in some HTML/PHP/Javascript mixing. >> >> Since the current namespace implementation doesn't want to have >> multiple namespaces per file, I think we should restrict a namespace >> per file to... a namespace per file, and nothing else. I can't imagine >> taking over someone's code who had declared a namespace under is >> footer template. >> >> Perhaps I am missing something but that would be bloody ugly in the end :) >> >> -- >> Slan, >> David >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > > -- > Lucas Stephanou > > > Ugh, don't top-post please the issue is without the patch, even an empty space or a newline at the start of a file will cause a fatal error Thanks, Elizabeth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
Hello Greg, please don't. marcus Friday, September 12, 2008, 9:11:39 PM, you wrote: > Hi, > This is a simple patch that allows files like this: > main.php: > > > template example > > > > namespace my::template; > // stuff ?>> > > to work without parse error. > Greg > P.S. this is the last outstanding namespace issue that I'm aware of > aside from the bracket wars, which is 100% philosophical, all the issues > fixed by my patches are functional problems in namespaces. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
My first msg in this list And I agree with you David. Mix html and namespace is very very ugly. 2008/9/12 David Coallier <[EMAIL PROTECTED]>: > 2008/9/12 Greg Beaver <[EMAIL PROTECTED]>: >> Hi, >> >> This is a simple patch that allows files like this: >> >> main.php: >> >> >> >> template example >> >> >> >> > namespace my::template; >> // stuff >> ?> >> >> > > Is it me or this doesn't look really clean? I have a clear idea that > namespaces are there to add an extra structural layer to the code and > not to be randomly used in some HTML/PHP/Javascript mixing. > > Since the current namespace implementation doesn't want to have > multiple namespaces per file, I think we should restrict a namespace > per file to... a namespace per file, and nothing else. I can't imagine > taking over someone's code who had declared a namespace under is > footer template. > > Perhaps I am missing something but that would be bloody ugly in the end :) > > -- > Slan, > David > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Lucas Stephanou -- Lucas Stephanou -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Scoping of "use" statements and a strategy for 5.3/6.0 release of namespace
Hi Stan,
I realized I missed 2 of your points, response below:
Hi,
Thanks for your work on resolving these issues. My comments about
use/namespace being a hack regards just the syntax, I was wrong about the
scoping of use, but also having "namespace" act as a scope without the scope
syntax {} will possibly be confusing. But, it'll work fine enough.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] the namespace war
So, after this msg(my second on list) maybe you will scream with me, but.
This namespace war is putting you focus on a great feature, but maybe
losing time with lot of discussion.
namespace foo;
or
namespace foo{
(...)
}
are both good options, but can we stop the war and go forward, as php
user I was losing with this fight.
My opinion is that
namespace foo{}
is best for all, some cache systems that rely on concat files maybe
will break with namespace; option
ps.: sorry for breaking this discussion on the middle
--
Lucas Stephanou
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
2008/9/12 Greg Beaver <[EMAIL PROTECTED]>: > Hi, > > This is a simple patch that allows files like this: > > main.php: > > > > template example > > > > namespace my::template; > // stuff > ?> > > Is it me or this doesn't look really clean? I have a clear idea that namespaces are there to add an extra structural layer to the code and not to be randomly used in some HTML/PHP/Javascript mixing. Since the current namespace implementation doesn't want to have multiple namespaces per file, I think we should restrict a namespace per file to... a namespace per file, and nothing else. I can't imagine taking over someone's code who had declared a namespace under is footer template. Perhaps I am missing something but that would be bloody ugly in the end :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
Hi,
This is a simple patch that allows files like this:
main.php:
template example
to work without parse error.
Greg
P.S. this is the last outstanding namespace issue that I'm aware of
aside from the bracket wars, which is 100% philosophical, all the issues
fixed by my patches are functional problems in namespaces.
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.85
diff -u -u -r1.647.2.27.2.41.2.85 zend_compile.c
--- Zend/zend_compile.c 29 Aug 2008 10:17:08 - 1.647.2.27.2.41.2.85
+++ Zend/zend_compile.c 12 Sep 2008 19:07:42 -
@@ -504,13 +504,17 @@
}
-void zend_do_echo(const znode *arg TSRMLS_DC)
+void zend_do_echo(const znode *arg, int is_html TSRMLS_DC)
{
zend_op *opline = get_next_op(CG(active_op_array) TSRMLS_CC);
opline->opcode = ZEND_ECHO;
opline->op1 = *arg;
- SET_UNUSED(opline->op2);
+ if (is_html) {
+ opline->op2.op_type = IS_CONST; /* tell zend_do_namespace that
INLINE_HTML is OK */
+ } else {
+ SET_UNUSED(opline->op2);
+ }
}
void zend_do_abstract_method(const znode *function_name, znode *modifiers,
const znode *body TSRMLS_DC)
@@ -5040,10 +5044,11 @@
char *lcname;
if (CG(active_op_array)->last > 0) {
- /* ignore ZEND_EXT_STMT and ZEND_TICKS */
+ /* ignore ZEND_EXT_STMT and ZEND_TICKS and T_INLINE_HTML */
int num = CG(active_op_array)->last;
while (num > 0 &&
(CG(active_op_array)->opcodes[num-1].opcode ==
ZEND_EXT_STMT ||
+ (CG(active_op_array)->opcodes[num-1].opcode ==
ZEND_ECHO && CG(active_op_array)->opcodes[num-1].op2.op_type == IS_CONST) ||
CG(active_op_array)->opcodes[num-1].opcode ==
ZEND_TICKS)) {
--num;
}
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.33
diff -u -u -r1.316.2.8.2.12.2.33 zend_compile.h
--- Zend/zend_compile.h 29 Aug 2008 18:12:47 - 1.316.2.8.2.12.2.33
+++ Zend/zend_compile.h 12 Sep 2008 19:07:42 -
@@ -385,7 +385,7 @@
void fetch_string_offset(znode *result, const znode *parent, const znode
*offset TSRMLS_DC);
void zend_do_fetch_static_member(znode *result, znode *class_znode TSRMLS_DC);
void zend_do_print(znode *result, const znode *arg TSRMLS_DC);
-void zend_do_echo(const znode *arg TSRMLS_DC);
+void zend_do_echo(const znode *arg, int is_html TSRMLS_DC);
typedef int (*unary_op_type)(zval *, zval * TSRMLS_DC);
typedef int (*binary_op_type)(zval *, zval *, zval * TSRMLS_DC);
ZEND_API unary_op_type get_unary_op(int opcode);
Index: Zend/zend_language_parser.y
===
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.160.2.4.2.8.2.26
diff -u -u -r1.160.2.4.2.8.2.26 zend_language_parser.y
--- Zend/zend_language_parser.y 29 Aug 2008 17:54:29 -
1.160.2.4.2.8.2.26
+++ Zend/zend_language_parser.y 12 Sep 2008 19:07:42 -
@@ -236,7 +236,7 @@
| T_GLOBAL global_var_list ';'
| T_STATIC static_var_list ';'
| T_ECHO echo_expr_list ';'
- | T_INLINE_HTML { zend_do_echo(&$1 TSRMLS_CC); }
+ | T_INLINE_HTML { zend_do_echo(&$1, 1
TSRMLS_CC); }
| expr ';'{ zend_do_free(&$1
TSRMLS_CC); }
| T_UNSET '(' unset_variables ')' ';'
| T_FOREACH '(' variable T_AS
@@ -556,8 +556,8 @@
;
echo_expr_list:
- echo_expr_list ',' expr { zend_do_echo(&$3 TSRMLS_CC); }
- | expr{ zend_do_echo(&$1
TSRMLS_CC); }
+ echo_expr_list ',' expr { zend_do_echo(&$3, 0 TSRMLS_CC); }
+ | expr{ zend_do_echo(&$1, 0
TSRMLS_CC); }
;
Index: Zend/tests/ns_076.phpt
===
RCS file: Zend/tests/ns_076.phpt
diff -N Zend/tests/ns_076.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/ns_076.phpt 12 Sep 2008 19:07:42 -
@@ -0,0 +1,26 @@
+--TEST--
+076: T_INLINE_HTML prior to namespace declaration
+--FILE--
+hi there
+
+===DONE===
+--EXPECT--
+hi there
+string(3) "foo"
+string(0) ""
+string(3) "foo"
+===DONE===
Index: Zend/tests/ns_077.phpt
===
RCS file: Zend/tests/ns_077.phpt
diff -N Zend/tests/ns_077.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/ns_077.phpt 12 Sep 2008 19:07:42 -
@@ -0,0 +1,21 @@
+--TEST--
+076: T_ECHO prior to namespace declaration
+--FILE--
+
+===DONE===
+--
Re: [PHP-DEV] Making ereg extension optional ?
hi, On Fri, Sep 12, 2008 at 6:21 PM, Arnaud Le Blanc <[EMAIL PROTECTED]> wrote: > Hi, > > PHP now builds and works without ereg, is it planed to make it optional ? It is planed to drop it so I suppose optional can be a first step. I remember something about adding a BC layer using pcre, I'm not sure if it is done yet. However I would not do it in 5.x. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Making ereg extension optional ?
Hi, PHP now builds and works without ereg, is it planed to make it optional ? Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
