Re: [PHP-DEV] namespace RFC
Lukas Kahwe Smith schreef: On 31.08.2008, at 15:37, Lukas Kahwe Smith wrote: Hello all, All the recent discussions about namespaces, have left many of us wondering if our implementation is rock solid or not. However the discussions were not really well organized. This is why I am thankful that Marcus and Felipe have spend the better part of this Sunday to write an RFC [1] that hopefully summarizes all the key concerns. Also they have created a patch that they feel addresses the concerns. [1] http://wiki.php.net/rfc/namespacecurlies I have also asked in my blog about practical experiences from people using PHP 5.3.0 with namespaces in development: http://pooteeweet.org/blog/1288 The gist in the first 2 responses seem to be that they are ok with the current state of things. they both admit they don't do (or are not interested in) the major point the RFC tries to tackle (i.e. file concatenation). subsequent posts do point out problems: 1. non-deterministic (a.k.a error prone) __autoloading issues - IFAIC Greg's arguments are sound, Stanislav's performance arguments are bogus (imho) simply because, up until the point that the new functionality is stable, complete and devoid of the WTF-factor it's performance should be ignored ... make it work, then make it fast? 2. namespaced constants/functions not autoloadable 3. namespaced functions not aliasable 4. the abiguity with static methods and namespaced functions - Elizabeth states this very succinctly. 5. inordinate number of use statements 6. internal classes being 'favored' over user classes. - which is likely to mean people will either avoid namespaces, avoid use statements or worse still miss a use statement now and again ... see point 1. If you ask me a major issue stems from the fact that the namespace scope operator was chosen to be the same as the class scope operator, even if this incurred no technical problems (which, I think, point 4 is), it still incurs the potential for major WTF when simply reading code - at the very least having to constantly check the 'use' statements at the top of a file to determine the actually referred to 'element'. Lukas, you stated a while back you were nervous about the namespace functionality, I believe you are right to be so. what there is currently will most likely do the opposite of what it is intended to ... the intention being, I assume, to increase php's 'enterprise level' functionality appearance (in terms of suitability). rgds, Jochem PS - please be a Dictator! currently it seems that the dev that shouts the loudest gets to shove his opinion/implementation down everyone's neck regardless of anyone's objections (however sound) ... even when those objections come from other devs, which makes a farce of the concept of meritocracy, besides nothing about open source suggested it's development process needs to be done by commitee. the more I think about it the more I believe php would benefit from a benevolent dictator ... who that might be is a more difficult question to answer, one steeped in politics. I could offer about 3 names that I think would suit the position, but I doubt anyone of 'importance' has read this far and if they had they probably attribute about as much weight to my opinions as they do to the average life of an ameoba. Anyways, anyone who cares should make their opinion known on this list as clear as possible by Monday (if someone is aware of a good discussion outside of internals please also let us know), so that Johannes and I can make a decision no later than Tuesday without having to feel like dictators. Personally at this point I would leave things as is for now, move to beta and hope that this also increases the number of end users testing and giving feedback. While I hope that we dont have to do big changes after going to beta, if feedback makes it necessary, we obviously have to accept it. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace RFC
On 31.08.2008, at 15:37, Lukas Kahwe Smith wrote: Hello all, All the recent discussions about namespaces, have left many of us wondering if our implementation is rock solid or not. However the discussions were not really well organized. This is why I am thankful that Marcus and Felipe have spend the better part of this Sunday to write an RFC [1] that hopefully summarizes all the key concerns. Also they have created a patch that they feel addresses the concerns. [1] http://wiki.php.net/rfc/namespacecurlies I have also asked in my blog about practical experiences from people using PHP 5.3.0 with namespaces in development: http://pooteeweet.org/blog/1288 The gist in the first 2 responses seem to be that they are ok with the current state of things. Anyways, anyone who cares should make their opinion known on this list as clear as possible by Monday (if someone is aware of a good discussion outside of internals please also let us know), so that Johannes and I can make a decision no later than Tuesday without having to feel like dictators. Personally at this point I would leave things as is for now, move to beta and hope that this also increases the number of end users testing and giving feedback. While I hope that we dont have to do big changes after going to beta, if feedback makes it necessary, we obviously have to accept it. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace RFC
Hi! So I ask you all to review the RFC and provide feedback. If you feel Here's my feedback on the RFC. 1. The RFC seems to assume or imply that PHP programmers have extensive C++ experience. IMHO it is not true for the majority of PHP programmers. 2. Phar has nothing to do with file concatenation, as if was noted, and concatenation's use is entirely unrelated to phar (and, before you mention it, to bytecode caches - they can be used together, but one does not preclude the other). 3. Namespaces are *NOT* code flow control structure. Giving it a syntax of a control structure is misleading, requiring endnamespace at the end of each file makes no sense and just adds busywork for people. It also is awfully ugly - braces at least have some decent looks... Namespace also is not like a label in any way - it does not specify point in code and you can not jump to it using either conditional (like switch/case:) or unconditional (like goto) branch. 4. I did not understand first paragraph of part named Statements outside namespaces - what is has to do with caches? Could somebody explain it to me (private mail/IRC/IM OK). 5. I am not sure which exactly code RFC proposes to allow outside namespaces, in any case I don't see why it is necessary to allow any code to be put outside namespaces in namespaced files. For include, it doesn't matter anyway, since included file has its own namespace, for the rest I'm just unclear what else is proposed, please explain. 6. Comment about we kind of allow nested namespaces because we allow namespace in included file is wrong. These namespaces live absolutely separately and are not nested in any meaningful way. All files in PHP except for the head script are obtained by means of include(), so it is only natural that namespace is allowed inside include - it would be useless otherwise. Included file, however, creates it own namespacing scope, and just as we do not say we allow nested classes because file defining class can be included from inside any other class, same holds for namespaces. 7. Nested namespaces. I see that RFC authors chose to completely ignore all my comments about namespace nesting, so I repeat them again for the record. Nesting namespaces implies hierarchy, hierarchy implies hierarchical resolution, so if you inside namespace A::B::C::D::E::F, then name G is expected to resolve when it means either A::G, A::B::G, A::B::C::G, etc. Combined with autoloading, this makes resolution process prohibitively expensive, and not resolvable in runtime by any means - since even if you wrote A::B::C::D::E::F::G it could still mean A::B::C::A::B::C::D::E::F::G - since you have not one-level resolution but hierarchical resolution, even qualified name could be partial name. Making nesting without hierarchy doesn't make any sense - why nest then, what purpose would it serve? Another objection for nesting would be that there's actually no practical use for it in real code - as you could not nest across file boundaries, only use would be if you pack substantial number of classes from different modules into a single file, which usually is a bad idea. If you follow standards accepted by many common applications and separate classes in different files, nesting is completely useless, so it is if you group closely related classes (they would probably then be in the same hierarchy level). So, summarily, right now I see serious technical challenge for nesting (hierarchical lookups) and I don't see real use case for it. Regards, -- 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] namespace RFC
Hi! I am sorry but I absolutely fail to see how the following is in any way whatsoever unclear: This is clear, I understand that and think it is completely wrong and misguided, for reasons I described in my last email. What I did not understand is what code you wanted to allow outside namespaces and what all that include part and strings/not strings distinction talks about. namespace A::B::C::D::E::F; $obj = new G; Now what? Now G is either A::B::C::D::E::F::G or ::G, but never A::B::G etc. Do you understand the difference? No hierarchy. -- 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
[PHP-DEV] namespace RFC
Hello all, All the recent discussions about namespaces, have left many of us wondering if our implementation is rock solid or not. However the discussions were not really well organized. This is why I am thankful that Marcus and Felipe have spend the better part of this Sunday to write an RFC [1] that hopefully summarizes all the key concerns. Also they have created a patch that they feel addresses the concerns. So I ask you all to review the RFC and provide feedback. If you feel something is missing, the best approach is probably to work with Marcus and Felipe directly to get your concerns added. Only if there is a difference of opinion in this process should this be brought to internals. This way we can hopefully keep the discussion more focused on actual differences, while making sure that the RFC covers most concerns in one coherent document. If there are very large and fundamental differences in opinion I encourage the creation of an alternate RFC (and patch in case the RFC requires changes to the codebase - which means you can also write an RFC to clarify the current behavior on why it makes sense). As you all hopefully know we have planned an alpha2 release for next Tuesday [2]. At this stage I guess we should continue with that plan and in case we need to make any bigger changes to namespaces (like this RFC suggests), we will probably have to accept an alpha3 release within 2-3 weeks time. Can't say I am happy about this, but I am quite positive that bringing this discussion to a slightly more formal level will give us a chance to make sure that in the end we can release PHP 5.3.0 with confidence. regards, Lukas Kahwe Smith [EMAIL PROTECTED] [1] http://wiki.php.net/rfc/namespacecurlies [2] http://wiki.php.net/todo/php53 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
