Re: [PHP-DEV] 5.3 Release Planning
Hi Johannes, This bug suggests the output buffering re-write in HEAD would be backported to 5_3: http://bugs.php.net/bug.php?id=42641 Is that still in plan? I have added it as a To be discussed item on http://wiki.php.net/todo/php53. Regards, Robin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Release Planning
On Mon, Mar 10, 2008 at 6:41 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I must be misunderstanding the patch then - doesn't it change behavior of the engine so that parent:: doesn't mean parent of __CLASS__ anymore? If so, could you explain again what it does? Of course parent:: still means parent. The change in behavior from the current patch is just that once you call parent::someMethod you will still have access to overridden methods in child classes which with the current patch is not possible. Again, it just provides complete polymorphism for statics. parent:: is very simple thing - it means use the name of the parent class here. I do not thing changing it is a good idea. I am of the opinion that parent:: simply means call the parent function which doesn't change with the patch. I understand that you do not think it is a good, but I and many other people that have expressed their opinion on list regarding this matter disagree with you. You seem to be very focused on the parent:: issue without looking at the whole picture. Like I said before, I think all of the arguments have been hashed out. I would just like a yes or no decision that preferably reflects the desire of the user base. It would be fantastic if some more decision makers had some time to give their input. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [PHP-DEV] 5.3 Release Planning
Hi! Of course parent:: still means parent. The change in behavior from the current patch is just that once you call parent::someMethod you will still have access to overridden methods in child classes which with the current patch is not possible. Again, it just provides complete polymorphism for statics. OK, looks like I misunderstood what your patch does. Sorry for that. However, I'm still concerned that foo:: and parent:: would work differently. IMO, better solution would be to have all :: calls change called_class, but have also some way to call it without changing called_class. Something like your forward_static_call, but I'm not sure not using callbacks is a good idea - all caller function use callbacks now. Actually, what I'd do would be to generalize forward_static_call (which I think also needs better name :) and call_user_func into one function (internally) that has parameter which tells if to update or not update called_class. -- 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] 5.3 Release Planning
On Tue, Mar 11, 2008 at 4:31 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: IMO, better solution would be to have all :: calls change called_class, but have also some way to call it without changing called_class. Something like your forward_static_call, but I'm not sure not using callbacks is a good idea - all caller function use callbacks now. Actually, what I'd do would be to generalize forward_static_call (which I think also needs better name :) and call_user_func into one function (internally) that has parameter which tells if to update or not update called_class. I do agree about using a callback with forward_static_call, but one thing that worries me is that opens the door to really bizzare functionality where the called_class could wind up being outside of the inheritance chain of the method being called. If this could be overcame I think it would be relatively easy to consolidate this code internally. I will look at it this evening and tomorrow. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [PHP-DEV] 5.3 Release Planning
Hi Mike, Am Sonntag, den 09.03.2008, 21:52 -0700 schrieb Mike Lively: [...] +1 for lsb.parent-forwarding.patch as the implemented behaviour will be expected from our users anyway. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] 5.3 Release Planning
Hi! One thing that never really was resolved were the patches I submitted as a compromise to some of the early disagreements about late static binding. I don't think it's a good ideas as it changes the meaning of parent::. -- 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] 5.3 Release Planning
On Mon, Mar 10, 2008 at 9:49 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! One thing that never really was resolved were the patches I submitted as a compromise to some of the early disagreements about late static binding. I don't think it's a good ideas as it changes the meaning of parent::. I disagree, the meaning of parent:: is not changed at all relative to php 5.2.*. It behaves exactly the same with the parent forwarding patch. If you call parent::method() the parent version of the method is still called. It just provides complete polymorphic calls with static functions which is the whole purpose for which LSB was even proposed. Regardless of that, there are two other patches that do the same thing without altering the behaviour of parent in the current 5.3 code. Though again, I would think it very unfortunate should we not fix it properly and just allow parent:: to forward the caller. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [PHP-DEV] 5.3 Release Planning
I disagree, the meaning of parent:: is not changed at all relative to php 5.2.*. It behaves exactly the same with the parent forwarding patch. I must be misunderstanding the patch then - doesn't it change behavior of the engine so that parent:: doesn't mean parent of __CLASS__ anymore? If so, could you explain again what it does? without altering the behaviour of parent in the current 5.3 code. Though again, I would think it very unfortunate should we not fix it properly and just allow parent:: to forward the caller. parent:: is very simple thing - it means use the name of the parent class here. I do not thing changing it is a good idea. -- 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] 5.3 Release Planning
On Thu, Mar 6, 2008 at 10:10 AM, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi all, recently there were quite a few proposals about stuff for 5.3. If we implement them all we won't finish in a soonish time and we get new ideas postponing the 5.3 release therefore the following: One thing that never really was resolved were the patches I submitted as a compromise to some of the early disagreements about late static binding. http://marc.info/?l=php-internalsm=119605755711936w=2 There was a little bit of discussion but it was quickly overshadowed by talk of brackets, imports, and other things. I don't necessarily think all of the arguments need to be rehashed again as they have been beaten to death, it would just be good to get an actual decision on whether or not one of them (hopefully the parent:: one) can make it in. If so I can update whichever patch.
Re: [PHP-DEV] 5.3 Release Planning
i just hope the issue described in http://www.mail-archive.com/internals@lists.php.net/msg32601.html will be resolved before 5.3 is out. it is the only problem that breaks opcode cacher support as far as i can see by now. e.g.: with this problem fixed, all test cases will pass when XCache is enabled but not without fixed -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.3 Release Planning
The patch for this issue is sent to @internals. It will be probably commited on next week. Please try to play with it. Thanks. Dmitry, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of phpxcache Sent: Friday, March 07, 2008 12:27 PM To: Johannes Schluter Cc: PHP Internals List Subject: Re: [PHP-DEV] 5.3 Release Planning i just hope the issue described in http://www.mail-archive.com/internals@lists.php.net/msg32601.h tml will be resolved before 5.3 is out. it is the only problem that breaks opcode cacher support as far as i can see by now. e.g.: with this problem fixed, all test cases will pass when XCache is enabled but not without fixed -- 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] 5.3 Release Planning
gotcha, i'll check it within 24hours thanks for your great work -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Release Planning
Hello Johannes, Thursday, March 6, 2008, 6:10:27 PM, you wrote: Hi all, recently there were quite a few proposals about stuff for 5.3. If we implement them all we won't finish in a soonish time and we get new ideas postponing the 5.3 release therefore the following: - Scanner based on re2c: [...] Anyone interested more in this one might a) have a look here: http://blog.somabo.de/2008/02/php-on-re2c.html b) provide tests for configure --enable-zend-multibyte (and whatever you use it for) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Release Planning
On 06.03.2008 20:10, Johannes Schlüter wrote: Hi all, recently there were quite a few proposals about stuff for 5.3. If we implement them all we won't finish in a soonish time and we get new ideas postponing the 5.3 release therefore the following: I'd like to ask to re-consider dropping ze1_compatibility_mode and finally drop it in 5.3. It just doesn't work, so there is no point to keep it. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Release Planning
- bundling pecl/intl According to Stas it's ready for being bundled and was voted in. The only Most of it is ready, since 5.3 took more time that we initially thought we also added dateformatter functionality there, which right now has last wrinkles straightened out - code is mostly complete, docs in the works, there might be minor API optimizations and bugfixes, but in general we could certainly merge it by the end of April. I don't want to symlink it until we have the code 100% done, but we are very close. -- 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] 5.3 Release Planning
Hi! Also will be nice if zend.enable_gc ini setting is dropped as well before it is too late , having yet another ini setting that alters the engine behaviuor looks pretty much like the repeating the same old mistakes over and over again. Does it alter the engine behaviour? I was under impression the behavior is the same, just the moment when memory is reclaimed has changed. Does it mean there's code that works differently with GC than without? -- 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] 5.3 Release Planning
-Original Message- From: Antony Dovgal [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2008 9:36 AM To: Johannes Schlüter Cc: PHP Internals List Subject: Re: [PHP-DEV] 5.3 Release Planning I'd like to ask to re-consider dropping ze1_compatibility_mode and finally drop it in 5.3. It just doesn't work, so there is no point to keep it. Yes I think it makes sense. Do we just document it in the UPGRADING doc or for 5.3 raise an E_ERROR with an error message? s
RE: [PHP-DEV] 5.3 Release Planning
-Original Message- From: Cristian Rodriguez [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2008 10:03 AM To: php-dev Subject: Re: [PHP-DEV] 5.3 Release Planning Also will be nice if zend.enable_gc ini setting is dropped as well before it is too late , having yet another ini setting that alters the engine behaviuor looks pretty much like the repeating the same old mistakes over and over again. either GC or dont, please. There is no functional implication and you will see the same behavior (except for memory usage and performance). Also I think we agreed this would not be a phpinfo() INI setting but one we can turn off for debugging purposes because until it's completely stable there may be GC bugs (we've had several). Also during the rollout process it'll help us triage performance issues if they come up (Turn it off and let us know if you feel a difference). Of course the bookkeeping is always on. So suggest to keep it in, not in phpinfo() and see how things roll out. Andi
