Hello Etienne,
Tuesday, August 12, 2008, 3:04:48 AM, you wrote:
> Hello,
> On Tue, Aug 12, 2008 at 2:39 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>> Hi!
>>
>>> but if the {} syntax is introduced, it will be made to affect only the
>>> code inside it, right? If so, I fail to see your point, since the new
>>> syntax will solve that problem.
>>
>> While introducing a whole collection of new problems - such as that we will
>> have now split scope, that you can get in and out many times in the same
>> file. As we discussed on the list many times, it's not exactly what we want
>> and definitely not the use case it was designed for. I don't see any use for
>> it besides promoting bad coding practices.
> To me
> namespace A {
> code
> }
> namespace B {
> code
> }
> code
> seems equivalent to
> namespace A;
> code
> namespace B;
> code
> namespace <none>;
> code
> Only nicer. And I can hardly how it's going to cause more problems?
> But if that's so, fine.
> My point is that if we are going to allow multiple namespaces per file
> solely on the perspective of permitting packaging, we should also
> allow mixing namespaced and non-namespaced code for that same
> perspective, and the current syntax is not going to allow that.
> I'd really like the {} syntax if multiple namespaces per file is
> allowed. If it's not, then it's not much more than syntactic sugar and
> I couldn't care less.
Exact same reasoning here. Now, I want to follow up with two things:
I) personal recent encounters
II) collection of argumenmts
III) personal preference
IV) what to do next
I) personal recent encounters
Technically it is pretty easy to come up with parser/lexer changes that
allow anything you want. Starting from real parser support for only one
namespace as the first statement per file down to muliple nested
namespaces after some initial code outside any namespace as in global,
patch for that attached. It does not include zend_language_scanner.c
and is not fully functionally. it just allows getting a feeling for
namespaces with curlies and and a potential limitationt to have non
namespaces code only prior to the first namespace keyword. Also it
could be done much easier but I wanted the extended info stuff the way
it is.
At the end of the day my biggest issues her are:
1) Namespaces without curly braces and concatenation of files lead to
difference code behavior.
I am not saying that curly braces would solve this fully per se, as you
could still use include/require statements. My point is rather that we
do not addredss this issue at all right now.
And btw, with curly braces we could at least disallow include/require
inside namespaces. Just as we don't allow include/require in classes
outside methods.
2) When we allow multiple namespaces per file for concatenation, then
why do we not allow code outside of namespaces. Because sooner or
later we want that too. We would want that for the exact reason we
want to have multiple namespaces today - concatenation of files.
However without curly braces we can never concatenate files with code
outside namespaces.
3) We are moving in the wrong direction here. Instead of keeping the
language easy we make it more complex to understand and deal with. And
the biggest reasons brought up so far are, circled around
- concatenation for speed
- whitespace
- which other language we relate to
I am really sorry for having to keep this running, but we are running
into somethign extremely bad. And it doesn't even work out in the long
run.
Another example. Remember when we first introduced cli? We thought of
adding a new file type that wouldn't need PIs (<?php...?>). We luckily
decided against that idea to keep the language easy. Without curlies we
will sooner or later be in a situation where there are two kinds of php
files. Those with namespaces and those without and they wouldn't be
able to cooperate.
II) collection of argumenmts
Let me try to summarize up to this point. The following options have been
outlined and discussed in more detail:
1) Kepp all as is: multiple 'namespace' declarations per file, no {}
+ For some people this means no additional whitespace (other people do
not have this issue, yet counted as +)
0 No direct nesting support (some like it, some don't)
0 Looks and feels more or less like Java packages
0 Original namespaces in pre 5.0beta had curlies
0 Is different from C++'s namespaces so it should look different,
more in: http://news.php.net/php.internals/39838
- Indirect nesting (only): php -r 'namespace foo; namespace foo::bar;'
- Like Java but allows multiple per file and has different keyword
- Multiple namespaces per file as a hack that is not meant to be used
- Two types of scripts, those with and those without namespaces, which
also prevents concatenation as a general solution if one file has
global code
- A file included in a namespaced method is not in that same namespace,
if we fix this we end up in different behavior of include/require for
namespe/non namespace files. If we disallow that, we make it harder
to understand when it is allowed and when not.
- A file included from a namespaced function/method body ends up in
that function method but not in its namespace:
http://lxr.php.net/source/ZendEngine2/tests/ns_069.phpt
http://lxr.php.net/source/ZendEngine2/tests/ns_069.inc
2) Change keyword 'namespace' to 'package'
0 Besides the file concatenation this would be exactly what Java does
- Namespace has been a reserved keyword, added 15th August 2007:
http://cvs.php.net/viewvc.cgi/phpdoc/en/appendices/reserved.xml?r1=1.66&r2=1.67
- 'Package' is not a reserved keyword at all
[The arguments of 1) aply]
2b) Like 2) but no multiple namespaces per file (no file concatenation)
0 Phar can be used to put several file in one anyway
3) Add curly braces to 'namespace'
+ Real nesting (some people don't like it but we support it anyway)
+ Allows for global, non namespaced code, and thus full concatenation of
files
0 Looks and feels exactly like C++ (besides we need to discuss whether to
allow code outside namespace).
0 Makes it a block structure like class which uses {}
- For some people this means additional whitespace (other people do not
have this issue, yet counted as -)
Why reuse keyword 'namespace' to identify root namespace (namespace::)?
- Why not use ':::' instead (re2c allows that easily) ?
Why no non namespced code?
- Issues with compiler caches
Do we need to support concatenation of files at all costs?
- We actually ship phar which allows to pack as many namespaced files
in a single php file, no matter what namespace support we end up
allowing.
III) personal preference
My preference is 3) and the next one would be 2) without file
concatenation support, as in one namespace per file only.
IV) what to do next
Someone should collect more arguments from the various threads (I am
sure there are more) and put them on a wiki. This pretty much looks
like a job for Lukas :-)
Best regards,
MarcusIndex: Zend/zend_compile.c
===================================================================
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.836
diff -u -p -d -r1.836 zend_compile.c
--- Zend/zend_compile.c 3 Aug 2008 11:47:09 -0000 1.836
+++ Zend/zend_compile.c 12 Aug 2008 10:24:29 -0000
@@ -5395,9 +5395,9 @@ void zend_do_namespace(znode *name TSRML
CG(active_op_array)->opcodes[num-1].opcode ==
ZEND_TICKS)) {
--num;
}
- if (!CG(current_namespace) && num > 0) {
- zend_error(E_COMPILE_ERROR, "Namespace declaration
statement has to be the very first statement in the script");
- }
+ //if (!CG(current_namespace) && num > 0) {
+ // zend_error(E_COMPILE_ERROR, "Namespace declaration
statement has to be the very first statement in the script");
+ //}
}
lcname = zend_u_str_case_fold(Z_TYPE(name->u.constant),
Z_UNIVAL(name->u.constant), Z_UNILEN(name->u.constant), 0, &lcname_len);
if (((lcname_len == sizeof("self")-1) &&
Index: Zend/zend_language_parser.y
===================================================================
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.210
diff -u -p -d -r1.210 zend_language_parser.y
--- Zend/zend_language_parser.y 12 Aug 2008 10:22:57 -0000 1.210
+++ Zend/zend_language_parser.y 12 Aug 2008 10:24:35 -0000
@@ -143,6 +143,7 @@
%token T_END_HEREDOC
%token T_DOLLAR_OPEN_CURLY_BRACES
%token T_CURLY_OPEN
+%token T_NAMESPACE_ROOT
%token T_PAAMAYIM_NEKUDOTAYIM
%token T_BINARY_DOUBLE
%token T_BINARY_HEREDOC
@@ -153,7 +154,8 @@
%% /* Rules */
start:
- top_statement_list { zend_do_end_compilation(TSRMLS_C); }
+ top_statement_list { zend_do_end_compilation(TSRMLS_C); }
+ | namespace_and_list { zend_do_end_compilation(TSRMLS_C); }
;
top_statement_list:
@@ -171,11 +173,37 @@ top_statement:
| function_declaration_statement {
zend_do_early_binding(TSRMLS_C); }
| class_declaration_statement {
zend_do_early_binding(TSRMLS_C); }
| T_HALT_COMPILER '(' ')' ';' {
zend_do_halt_compiler_register(TSRMLS_C); YYACCEPT; }
- | T_NAMESPACE namespace_name ';' { zend_do_namespace(&$2
TSRMLS_CC); }
| T_USE use_declarations ';'
| constant_declaration ';'
;
+namespace_and_list:
+ T_NAMESPACE namespace_declaration namespace_list
+;
+
+namespace_list:
+ namespace_list namespace_statement
+ | /* empty */
+;
+
+namespace_statement: // with
+ T_NAMESPACE { zend_do_extended_info(TSRMLS_C); }
namespace_declaration { HANDLE_INTERACTIVE(); }
+;
+
+namespace_declaration: // w/o
+ namespace_name '{' { zend_do_namespace(&$2 TSRMLS_CC); }
namespace_member_list '}'
+;
+
+namespace_member_list:
+ namespace_member_list { zend_do_extended_info(TSRMLS_C); }
namespace_member { HANDLE_INTERACTIVE(); }
+ | /*empty */
+;
+
+namespace_member:
+ top_statement
+ | T_NAMESPACE namespace_declaration
+;
+
use_declarations:
use_declarations ',' use_declaration
| use_declaration
@@ -695,14 +723,14 @@ function_call:
class_name:
T_STRING { $$ = $1; }
| T_STATIC { $$.op_type = IS_CONST;
ZVAL_ASCII_STRINGL(&$$.u.constant, "static", sizeof("static")-1, 1);}
- | T_NAMESPACE { $$.op_type = IS_CONST;
ZVAL_EMPTY_TEXT(&$$.u.constant); }
+ | T_NAMESPACE_ROOT { $$.op_type = IS_CONST;
ZVAL_EMPTY_TEXT(&$$.u.constant); }
| T_PAAMAYIM_NEKUDOTAYIM T_STRING {
zend_do_build_namespace_name(&$$, NULL, &$2 TSRMLS_CC); }
| class_name T_PAAMAYIM_NEKUDOTAYIM T_STRING {
zend_do_build_namespace_name(&$$, &$1, &$3 TSRMLS_CC); }
;
fully_qualified_class_name:
T_STRING { $$ = $1; }
- | T_NAMESPACE { $$.op_type = IS_CONST;
ZVAL_EMPTY_TEXT(&$$.u.constant); }
+ | T_NAMESPACE_ROOT { $$.op_type = IS_CONST;
ZVAL_EMPTY_TEXT(&$$.u.constant); }
| T_PAAMAYIM_NEKUDOTAYIM T_STRING {
zend_do_build_namespace_name(&$$, NULL, &$2 TSRMLS_CC); }
| fully_qualified_class_name T_PAAMAYIM_NEKUDOTAYIM T_STRING {
zend_do_build_namespace_name(&$$, &$1, &$3 TSRMLS_CC); }
;
Index: Zend/zend_language_scanner.l
===================================================================
RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.193
diff -u -p -d -r1.193 zend_language_scanner.l
--- Zend/zend_language_scanner.l 12 Aug 2008 09:39:39 -0000 1.193
+++ Zend/zend_language_scanner.l 12 Aug 2008 10:24:51 -0000
@@ -1603,6 +1603,10 @@ NOWDOC_CHARS ([^\n\r]|{NEWLINE}+(
goto restart;
}
+<ST_IN_SCRIPTING>":::" {
+ return T_NAMESPACE_ROOT;
+}
+
<ST_IN_SCRIPTING>"::" {
return T_PAAMAYIM_NEKUDOTAYIM;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
