Re: [PHP-DEV] Namespaces and __autoload()
On Mon, 27 Aug 2007, Dmitry Stogov wrote: In this case PHP first looks for Foo::Exception and only then for internal Exception, but the first lookup may call __autoload (or corresponding SPL functions) and it can emit error or throw exception. The patch provides an additional boolean argument to __autoload() that say if class is really required. In case if it false, user code shouldn't emit errors or throw exceptions. It looks like this is going to break BC. Are current autoload functions guaranteed to work with the new implementation? Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Namespaces and __autoload()
Existing __autoload() will work fine with code without namespaces. Dmitry. -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 11:44 AM To: Dmitry Stogov Cc: 'PHP Internals List' Subject: Re: [PHP-DEV] Namespaces and __autoload() On Mon, 27 Aug 2007, Dmitry Stogov wrote: In this case PHP first looks for Foo::Exception and only then for internal Exception, but the first lookup may call __autoload (or corresponding SPL functions) and it can emit error or throw exception. The patch provides an additional boolean argument to __autoload() that say if class is really required. In case if it false, user code shouldn't emit errors or throw exceptions. It looks like this is going to break BC. Are current autoload functions guaranteed to work with the new implementation? Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: Re: [PHP-DEV] What should be in 5.3?
On Mon, 27 Aug 2007, Andi Gutmans wrote: I think we're still far away from a working garbage collector which is production quality. At least last time we were discussing it. This should still remain a PHP 6 item if we can actually make it works in an acceptable way. Have you checked the latest patch that david send here? He updated quite a bit to address all the issues that were raised as far as I know. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces and __autoload()
Why don't we add an optional second argument to __autoload() that receives the fully qualified namespace name of the class that should be autoloaded? That doesn't break BC and it prevents conflicts. David Am 27.08.2007 um 19:49 schrieb Stanislav Malyshev: ?php namespace Foo; throw new Exception; In this case PHP first looks for Foo::Exception and only then for internal Exception, but the first lookup may call __autoload (or corresponding SPL functions) and it can emit error or throw exception. The patch provides an additional boolean argument to __autoload() that say if class is really required. In case if it false, user code shouldn't emit errors or throw exceptions. There's two problems here: 1. On each access to internal class, like Exception, SPL classes, DateTime, reflection classes, etc. - we'd have call to autoload and subsequent disk access, maybe more than one if we have include path. Performance of it would be awful. 2. All libraries having autoloaders would have to rewrite them to support the new mode. I would propose different solution. When we have unresolved unqualified name, we do the following: 1. Check if we already know such class in namespace at compile- time. If so, it's resolved. 2. If not, will be resolved at run-time. 3. At run-time, check if we know such class in namespace now. If yes, it's resolved. 4. If not, check if we know internal class with such name. If yes, it's resolved to internal class. 5. If not, try to autoload this class. If autoloading fails, it's the undefined class error. This rule is a bit more complex, but allows to resolve common cases without extra filesystem accesses and allows to keep autoloader without modification. Comments? -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces and __autoload()
Why don't we add an optional second argument to __autoload() that receives the fully qualified namespace name of the class that should be autoloaded? That doesn't break BC and it prevents conflicts. The first argument already receives that, why would you need the second one? -- 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: Re: [PHP-DEV] What should be in 5.3?
On 8/27/07, Andi Gutmans [EMAIL PROTECTED] wrote: I think we're still far away from a working garbage collector which is production quality. Im sure it has bugs, but last time I tested the circular repository it was working really fine and the save of memory was really big ;-) -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] What should be in 5.3?
Hi all, From my point of view I think we can make a really good PHP 5.3 release pretty quickly as long as we are careful about the scope. There's a lot of good work which is low risk which we can easily roll into it. There are high risk items like garbage collection etc. which I think we should continue working on, etc. but target them more towards PHP 6. Adding such features into a PHP 5.3 branch wouldn't allow us to release that for a long time. I think schedule wise it's not unreasonable to do a pretty feature rich PHP 5.3 beta in November and release in January. I prefer the release-early, release-often mantra and that'll require us to somewhat be careful about the scope and high risk items. The following are some suggestions we (Dmitry, Stas and I) have re: items we had on our lists. We divided them into what we think are must-haves (i.e. don't release without), should-haves (we should try to get these in but they wouldn't be show stoppers for release), and nice to-haves (low priority). Must have: These are ones that we'd really like to be in 5.3 and think should delay 5.3 release if they aren't ready. 1. ICU extension 2. OpenSSL modifications for OpenID 3. Dynamic class access ($class::method) 4. (binary) operator which is the same as (string) 5. remove --enable-fastcgi and family, always enable them 6. __callStatic friends 7. remove warning for var Should have: These are ones that we'd like to be in 5.3, but if there are problems with them we are ready to go without them and catch up in 5.3.x, 5.4, etc. 1. Unicode extension (normalization, character properties, etc.) 2. Late static binding 3. Namespaces (still needs maturing so that will be the main factor for deciding if in or out) 4. Make memory manager pluggable per-request (simple patch) 5. Synchronize all OO module docs to look the same (PHPDOC team) 6. remove undocumented support for strings in list($a,$b) = ab 7. Move arg_info and other C constants from .data to .text (or .rdata) segment 8. Non-parsed heredocs (nowdocs) Nice to have: These are ones that we'd like to have in 5.3, but are not important enough to spend energy on before first two groups are achieved (unless of course somebody has a good working implementation). 1. cookie2 support 2. stat cache for windows/unix 3. mysqlnd 4. goto 5. __construct in interfaces 6. Compiled functions (CFs) and classes in PHP 7. Allow parser to evaluate static expressions (-1, 2+2) in compile-time (it won't work with constants (X+1)) Our 2 cents. Andi -Original Message- From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] Sent: Monday, August 27, 2007 2:30 AM To: PHP Developers Mailing List Subject: [PHP-DEV] What should be in 5.3? Hi, In the spirit of forwards compabitility I think the 5.3 release will we very important regardless if we keep or remove the unicode switch in PHP6. From my POV 5.1 and 5.2 have mainly covered stability and performance improvements on top of the addition of several important extensions like PDO, Json etc. In terms of changes to the actual language the main thing that sticks in my head where things like E_STRICT and is_a vs. instanceOf. So now with 5.3 we might want to look ahead towards PHP6 and make sure that we add whatever makes sense to have in 5.x that will ease the life for people writing forward compatible code for PHP6. It might also be a chance to revisit the question of how we want to approach strictness and deprecation. Forward compatibility: - binary cast - namespaces - ... Strictness: - What is our philisophy, is OO more strict than procedural or is there no such differntiation? I remember the discussions about dynamic member variables, number incrementing throwing notices inconsistently, signature rewriting. I fear I am opening a can of worms with this one. Although I disagree with the bulk of the decisions on this topic in the past I am not trying to reopen the discussions, I just hope to get a clearer definition on our philosiphie for future discussions Deprecation: - Split of deprecation from E_STRICT - Rule for deprecation See the todo wiki for some hints on things currently planned (or that I heard people thinking about planning): http://oss.backendmedia.com/PhP53 http://oss.backendmedia.com/PhP60 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
