Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39870 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52006 invoked from network); 12 Aug 2008 13:36:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Aug 2008 13:36:45 -0000 Authentication-Results: pb1.pair.com header.from=helly@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=helly@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender) X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 85.214.94.56 aixcept.net Linux 2.6 Received: from [85.214.94.56] ([85.214.94.56:60054] helo=h1149922.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B6/4D-04075-AE191A84 for ; Tue, 12 Aug 2008 09:36:45 -0400 Received: from MBOERGER-ZRH (unknown [193.142.125.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by h1149922.serverkompetenz.net (Postfix) with ESMTP id 782C711EFBD; Tue, 12 Aug 2008 15:36:39 +0200 (CEST) Date: Tue, 12 Aug 2008 15:36:36 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <496879481.20080812153636@marcus-boerger.de> To: "Etienne Kneuss" CC: "Stanislav Malyshev" , hannes.magnusson@gmail.com, "Lukas Kahwe Smith" , In-Reply-To: References: <909776579.20080803142659@marcus-boerger.de> <840985F2-A701-4BE4-91F6-F6B39048CF9B@pooteeweet.org> <48A09FF4.1030101@zend.com> <7f3ed2c30808111411t51553771j389f05c3436bc625@mail.gmail.com> <48A0C415.9090104@zend.com> <48A0D579.2000000@zend.com> <48A0DBAE.2010401@zend.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------1001B91413DFA9E47" Subject: Re: [PHP-DEV] Inconsistencies in 5.3 From: helly@php.net (Marcus Boerger) ------------1001B91413DFA9E47 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Etienne, Tuesday, August 12, 2008, 3:04:48 AM, you wrote: > Hello, > On Tue, Aug 12, 2008 at 2:39 AM, Stanislav Malyshev 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 ; > 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 (). 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, Marcus ------------1001B91413DFA9E47 Content-Type: text/plain; name="php-nested-namespaces-20080812.diff.txt" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="php-nested-namespaces-20080812.diff.txt" SW5kZXg6IFplbmQvemVuZF9jb21waWxlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Jl cG9zaXRvcnkvWmVuZEVuZ2luZTIvemVuZF9jb21waWxlLmMsdgpyZXRyaWV2aW5nIHJldmlz aW9uIDEuODM2CmRpZmYgLXUgLXAgLWQgLXIxLjgzNiB6ZW5kX2NvbXBpbGUuYwotLS0gWmVu ZC96ZW5kX2NvbXBpbGUuYwkzIEF1ZyAyMDA4IDExOjQ3OjA5IC0wMDAwCTEuODM2CisrKyBa ZW5kL3plbmRfY29tcGlsZS5jCTEyIEF1ZyAyMDA4IDEwOjI0OjI5IC0wMDAwCkBAIC01Mzk1 LDkgKzUzOTUsOSBAQCB2b2lkIHplbmRfZG9fbmFtZXNwYWNlKHpub2RlICpuYW1lIFRTUk1M CiAJCSAgICAgICAgQ0coYWN0aXZlX29wX2FycmF5KS0+b3Bjb2Rlc1tudW0tMV0ub3Bjb2Rl ID09IFpFTkRfVElDS1MpKSB7CiAJCQktLW51bTsKIAkJfQotCQlpZiAoIUNHKGN1cnJlbnRf bmFtZXNwYWNlKSAmJiBudW0gPiAwKSB7Ci0JCQl6ZW5kX2Vycm9yKEVfQ09NUElMRV9FUlJP UiwgIk5hbWVzcGFjZSBkZWNsYXJhdGlvbiBzdGF0ZW1lbnQgaGFzIHRvIGJlIHRoZSB2ZXJ5 IGZpcnN0IHN0YXRlbWVudCBpbiB0aGUgc2NyaXB0Iik7Ci0JCX0KKwkJLy9pZiAoIUNHKGN1 cnJlbnRfbmFtZXNwYWNlKSAmJiBudW0gPiAwKSB7CisJCS8vCXplbmRfZXJyb3IoRV9DT01Q SUxFX0VSUk9SLCAiTmFtZXNwYWNlIGRlY2xhcmF0aW9uIHN0YXRlbWVudCBoYXMgdG8gYmUg dGhlIHZlcnkgZmlyc3Qgc3RhdGVtZW50IGluIHRoZSBzY3JpcHQiKTsKKwkJLy99CiAJfQog CWxjbmFtZSA9IHplbmRfdV9zdHJfY2FzZV9mb2xkKFpfVFlQRShuYW1lLT51LmNvbnN0YW50 KSwgWl9VTklWQUwobmFtZS0+dS5jb25zdGFudCksIFpfVU5JTEVOKG5hbWUtPnUuY29uc3Rh bnQpLCAwLCAmbGNuYW1lX2xlbik7CiAJaWYgKCgobGNuYW1lX2xlbiA9PSBzaXplb2YoInNl bGYiKS0xKSAmJgpJbmRleDogWmVuZC96ZW5kX2xhbmd1YWdlX3BhcnNlci55Cj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KUkNTIGZpbGU6IC9yZXBvc2l0b3J5L1plbmRFbmdpbmUyL3plbmRfbGFuZ3VhZ2Vf cGFyc2VyLnksdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjEwCmRpZmYgLXUgLXAgLWQgLXIx LjIxMCB6ZW5kX2xhbmd1YWdlX3BhcnNlci55Ci0tLSBaZW5kL3plbmRfbGFuZ3VhZ2VfcGFy c2VyLnkJMTIgQXVnIDIwMDggMTA6MjI6NTcgLTAwMDAJMS4yMTAKKysrIFplbmQvemVuZF9s YW5ndWFnZV9wYXJzZXIueQkxMiBBdWcgMjAwOCAxMDoyNDozNSAtMDAwMApAQCAtMTQzLDYg KzE0Myw3IEBACiAldG9rZW4gVF9FTkRfSEVSRURPQwogJXRva2VuIFRfRE9MTEFSX09QRU5f Q1VSTFlfQlJBQ0VTCiAldG9rZW4gVF9DVVJMWV9PUEVOCisldG9rZW4gVF9OQU1FU1BBQ0Vf Uk9PVCAKICV0b2tlbiBUX1BBQU1BWUlNX05FS1VET1RBWUlNCiAldG9rZW4gVF9CSU5BUllf RE9VQkxFCiAldG9rZW4gVF9CSU5BUllfSEVSRURPQwpAQCAtMTUzLDcgKzE1NCw4IEBACiAl JSAvKiBSdWxlcyAqLwogCiBzdGFydDoKLQl0b3Bfc3RhdGVtZW50X2xpc3QJeyB6ZW5kX2Rv X2VuZF9jb21waWxhdGlvbihUU1JNTFNfQyk7IH0KKwkJdG9wX3N0YXRlbWVudF9saXN0IHsg emVuZF9kb19lbmRfY29tcGlsYXRpb24oVFNSTUxTX0MpOyB9CisJfAluYW1lc3BhY2VfYW5k X2xpc3QgeyB6ZW5kX2RvX2VuZF9jb21waWxhdGlvbihUU1JNTFNfQyk7IH0KIDsKIAogdG9w X3N0YXRlbWVudF9saXN0OgpAQCAtMTcxLDExICsxNzMsMzcgQEAgdG9wX3N0YXRlbWVudDoK IAl8CWZ1bmN0aW9uX2RlY2xhcmF0aW9uX3N0YXRlbWVudAl7IHplbmRfZG9fZWFybHlfYmlu ZGluZyhUU1JNTFNfQyk7IH0KIAl8CWNsYXNzX2RlY2xhcmF0aW9uX3N0YXRlbWVudAkJeyB6 ZW5kX2RvX2Vhcmx5X2JpbmRpbmcoVFNSTUxTX0MpOyB9CiAJfAlUX0hBTFRfQ09NUElMRVIg JygnICcpJyAnOycJCXsgemVuZF9kb19oYWx0X2NvbXBpbGVyX3JlZ2lzdGVyKFRTUk1MU19D KTsgWVlBQ0NFUFQ7IH0KLQl8CVRfTkFNRVNQQUNFIG5hbWVzcGFjZV9uYW1lICc7Jwl7IHpl bmRfZG9fbmFtZXNwYWNlKCYkMiBUU1JNTFNfQ0MpOyB9CiAJfAlUX1VTRSB1c2VfZGVjbGFy YXRpb25zICc7JwogCXwJY29uc3RhbnRfZGVjbGFyYXRpb24gJzsnCiA7CiAKK25hbWVzcGFj ZV9hbmRfbGlzdDoKKwkJVF9OQU1FU1BBQ0UgbmFtZXNwYWNlX2RlY2xhcmF0aW9uIG5hbWVz cGFjZV9saXN0Cis7CisKK25hbWVzcGFjZV9saXN0OgorCQluYW1lc3BhY2VfbGlzdCBuYW1l c3BhY2Vfc3RhdGVtZW50CisJfAkvKiBlbXB0eSAqLworOworCituYW1lc3BhY2Vfc3RhdGVt ZW50OiAvLyB3aXRoCisJCVRfTkFNRVNQQUNFIHsgemVuZF9kb19leHRlbmRlZF9pbmZvKFRT Uk1MU19DKTsgfSBuYW1lc3BhY2VfZGVjbGFyYXRpb24gIHsgSEFORExFX0lOVEVSQUNUSVZF KCk7IH0KKzsKKworbmFtZXNwYWNlX2RlY2xhcmF0aW9uOiAvLyB3L28KKwkJbmFtZXNwYWNl X25hbWUgJ3snIHsgemVuZF9kb19uYW1lc3BhY2UoJiQyIFRTUk1MU19DQyk7IH0gbmFtZXNw YWNlX21lbWJlcl9saXN0ICd9JworOworCituYW1lc3BhY2VfbWVtYmVyX2xpc3Q6CisJCW5h bWVzcGFjZV9tZW1iZXJfbGlzdCAgeyB6ZW5kX2RvX2V4dGVuZGVkX2luZm8oVFNSTUxTX0Mp OyB9IG5hbWVzcGFjZV9tZW1iZXIgeyBIQU5ETEVfSU5URVJBQ1RJVkUoKTsgfQorCXwJLypl bXB0eSAqLworOworCituYW1lc3BhY2VfbWVtYmVyOgorCQl0b3Bfc3RhdGVtZW50CisJfAlU X05BTUVTUEFDRSBuYW1lc3BhY2VfZGVjbGFyYXRpb24KKzsKKwogdXNlX2RlY2xhcmF0aW9u czoKIAkJdXNlX2RlY2xhcmF0aW9ucyAnLCcgdXNlX2RlY2xhcmF0aW9uCiAJfAl1c2VfZGVj bGFyYXRpb24KQEAgLTY5NSwxNCArNzIzLDE0IEBAIGZ1bmN0aW9uX2NhbGw6CiBjbGFzc19u YW1lOgogCQlUX1NUUklORyB7ICQkID0gJDE7IH0KIAl8CVRfU1RBVElDIHsgJCQub3BfdHlw ZSA9IElTX0NPTlNUOyBaVkFMX0FTQ0lJX1NUUklOR0woJiQkLnUuY29uc3RhbnQsICJzdGF0 aWMiLCBzaXplb2YoInN0YXRpYyIpLTEsIDEpO30KLQl8CVRfTkFNRVNQQUNFIHsgJCQub3Bf dHlwZSA9IElTX0NPTlNUOyBaVkFMX0VNUFRZX1RFWFQoJiQkLnUuY29uc3RhbnQpOyB9CisJ fAlUX05BTUVTUEFDRV9ST09UICB7ICQkLm9wX3R5cGUgPSBJU19DT05TVDsgWlZBTF9FTVBU WV9URVhUKCYkJC51LmNvbnN0YW50KTsgfQogCXwJVF9QQUFNQVlJTV9ORUtVRE9UQVlJTSBU X1NUUklORyB7IHplbmRfZG9fYnVpbGRfbmFtZXNwYWNlX25hbWUoJiQkLCBOVUxMLCAmJDIg VFNSTUxTX0NDKTsgfQogCXwJY2xhc3NfbmFtZSBUX1BBQU1BWUlNX05FS1VET1RBWUlNIFRf U1RSSU5HIHsgemVuZF9kb19idWlsZF9uYW1lc3BhY2VfbmFtZSgmJCQsICYkMSwgJiQzIFRT Uk1MU19DQyk7IH0KIDsKIAogZnVsbHlfcXVhbGlmaWVkX2NsYXNzX25hbWU6CiAJCVRfU1RS SU5HIHsgJCQgPSAkMTsgfQotCXwJVF9OQU1FU1BBQ0UgeyAkJC5vcF90eXBlID0gSVNfQ09O U1Q7IFpWQUxfRU1QVFlfVEVYVCgmJCQudS5jb25zdGFudCk7IH0KKwl8CVRfTkFNRVNQQUNF X1JPT1QgIHsgJCQub3BfdHlwZSA9IElTX0NPTlNUOyBaVkFMX0VNUFRZX1RFWFQoJiQkLnUu Y29uc3RhbnQpOyB9CiAJfAlUX1BBQU1BWUlNX05FS1VET1RBWUlNIFRfU1RSSU5HIHsgemVu ZF9kb19idWlsZF9uYW1lc3BhY2VfbmFtZSgmJCQsIE5VTEwsICYkMiBUU1JNTFNfQ0MpOyB9 CiAJfAlmdWxseV9xdWFsaWZpZWRfY2xhc3NfbmFtZSBUX1BBQU1BWUlNX05FS1VET1RBWUlN IFRfU1RSSU5HIHsgemVuZF9kb19idWlsZF9uYW1lc3BhY2VfbmFtZSgmJCQsICYkMSwgJiQz IFRTUk1MU19DQyk7IH0KIDsKSW5kZXg6IFplbmQvemVuZF9sYW5ndWFnZV9zY2FubmVyLmwK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG9zaXRvcnkvWmVuZEVuZ2luZTIvemVuZF9s YW5ndWFnZV9zY2FubmVyLmwsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTkzCmRpZmYgLXUg LXAgLWQgLXIxLjE5MyB6ZW5kX2xhbmd1YWdlX3NjYW5uZXIubAotLS0gWmVuZC96ZW5kX2xh bmd1YWdlX3NjYW5uZXIubAkxMiBBdWcgMjAwOCAwOTozOTozOSAtMDAwMAkxLjE5MworKysg WmVuZC96ZW5kX2xhbmd1YWdlX3NjYW5uZXIubAkxMiBBdWcgMjAwOCAxMDoyNDo1MSAtMDAw MApAQCAtMTYwMyw2ICsxNjAzLDEwIEBAIE5PV0RPQ19DSEFSUyAgICAgICAgKFteXG5ccl18 e05FV0xJTkV9KygKIAlnb3RvIHJlc3RhcnQ7CiB9CiAKKzxTVF9JTl9TQ1JJUFRJTkc+Ijo6 OiIgeworCXJldHVybiBUX05BTUVTUEFDRV9ST09UOworfQorCiA8U1RfSU5fU0NSSVBUSU5H PiI6OiIgewogCXJldHVybiBUX1BBQU1BWUlNX05FS1VET1RBWUlNOwogfQo= ------------1001B91413DFA9E47--