Re: [PHP-DEV] PHP 6
if you mentioned windows builds, whats the current status of http://pecl4win.php.net/ ? Tyrael On Fri, Mar 12, 2010 at 6:54 AM, Lester Caine les...@lsces.co.uk wrote: Rafael Dohms wrote: 2010/3/11 Johannes Schlüterjohan...@php.net: On the other hand merging tests to5.2 and 5.3 means that we can find new BC breaks we had overseen and either fix them or document them properly. So I won't waste too much time but not forget about 5.2. As much as I agree with the push for 5.3 adoption, its surely not a reality with most of the community out there, like the hosting companies for example. So like last year i guess we should surely focus on 5.3, but not discourage any 5.2 work and keep writing the test for all across, 5.2, 5.3, 6.0 Everyone at our test fest did that, save in cases where the functionality was not available or altered, the tests we basically the same for all versions, and i even caught a few 5.2 issues in the process. I agree in keeping the tests alive for 5.2. Currently maintaining the 5.2 branch is essential until such time as all extensions are available in official builds of PHP on windows! Forcing projects to change their development platforms simply to support a blinkered set of rules on PHP is not helpful in moving the project forward. How many extensions are currently stable in 5.2 on windows but not supported in 5.3? Private builds of the extensions in 5.3 are running without problems but having to direct users to other sites is as bad as the current fragmentation in the core code? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- 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] PHP 6
Ferenc Kovacs wrote: if you mentioned windows builds, whats the current status of http://pecl4win.php.net/ ? Also only available for PHP5.2 ;) ( If you must top post TRIM :( ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
hi, On Thu, Mar 11, 2010 at 6:22 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: Ah, Jani went a little crazy today in his typical style to force a decision. The real decision is not whether to have a version 5.4 or not It is really annoying that no matter who says it, Jani keeps doing whatever he wants. That's not good for the development process and that will certainly not help new contributors to get attracted by PHP. Can we now revert the new OB API commit in 5.3 and kill this 5.4 branch as requested so many times already? So we can actually do what you suggested yesterday, define what's the next steps and todos, which release it will be and what it has to contain. That should hopefully help to get a good roadmap without a deluge of new features without any kind of discussions. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tests repository (was: Re: [PHP-DEV] PHP 6)
Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? Some changes / improvements are of course needed for the run-tests.php but IIRC, someone was rewriting it already? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository (was: Re: [PHP-DEV] PHP 6)
On Fri, Mar 12, 2010 at 11:18, Jani Taskinen jani.taski...@iki.fi wrote: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? Thats actually a fairly good idea. Some tests however are not supposed to work in earlier releases, so we need to either add a new ==SKIP-VERSION== 5.2, 5.1, 5.0 or add more things to skipif. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository (was: Re: [PHP-DEV] PHP 6)
On Fri, Mar 12, 2010 at 11:18 AM, Jani Taskinen jani.taski...@iki.fi wrote: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? BC tests and easiness are two of the reasons why we have a donwloadable phpt packages on the windows download pages. Some changes / improvements are of course needed for the run-tests.php but IIRC, someone was rewriting it already? Can we use this svn link/external somehow? Having one module for the tests but you get them when checking out a php-src branch. Gwynne can certainly answer this question :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
Hannes Magnusson wrote: On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taski...@iki.fi wrote: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? Thats actually a fairly good idea. Some tests however are not supposed to work in earlier releases, so we need to either add a new ==SKIP-VERSION== 5.2, 5.1, 5.0 or add more things to skipif. Further - that might also offer a path for identifying better what features are added with a version? I'm still having fun with some aspects of making code compatible to 5.3 while still working with PHP4. Ideally it would have been nice to freeze our last 5.2 builds as the final PHP4 compatible versions, but 5.3 crept out in the field and so we have a bit of a mess with people complaining about 'bugs' which are simply warning messages. On one hand telling them how to change PHP settings to ignore them is probably the correct action, but you all know what users are like ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 03/12/2010 12:29 PM, Hannes Magnusson wrote: On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taski...@iki.fi wrote: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? Thats actually a fairly good idea. Some tests however are not supposed to work in earlier releases, so we need to either add a new ==SKIP-VERSION== 5.2, 5.1, 5.0 Perhaps something like required min version is better. Any ideas who has been working on the improved test stuff? Or was that just a dream? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 as we know it suddenly died?
2010-03-11 18:22, Rasmus Lerdorf skrev: Ah, Jani went a little crazy today in his typical style to force a decision. The real decision is not whether to have a version 5.4 or not, it is all about solving the Unicode problem. The current effort has obviously stalled. We need to figure out how to get development back on track in a way that people can get on board. We knew the Unicode effort was hugely ambitious the way we approached it. There are other ways. So I think Lukas and others are right, let's move the PHP 6 trunk to a branch since we are still going to need a bunch of code from it and move development to trunk and start exploring lighter and more approachable ways to attack Unicode. We have a few already. Enhanced mbstring and ext/intl. Let's see some good ideas around that and work on those in trunk. Other features necessarily need to play along with these in the same branch. I refuse to go down the path of a 5.4 branch and a separate Unicode branch again. Just to be clear about what is being discussed, since this sounds to me like everything Unicode will happen in functions and classes only. 1. Are you proposing that unicode strings disappear? 2. If so, what will happen to array access in strings that are de facto Unicode? Will the more clunky mb_substr() be the only option? 3. Will PHP ever reach a state where Unicode is the default encoding with this approach? I.e. will I ten years from now still write mb_strlen($foo, utf-8) if I do not overload normal PHP functions? UTF-8 marketshare is rising steadily. More than 50 % of all new projects on the web use it. By 2015 I'd suspect that only legacy projects will be non-unicode and a great number of them will be in the process of converting. Somewhere in the future PHP must default to Unicode! As for naming. Releasing PHP 6 without the up until now proposed Unicode functionality will be confusing. Learn from ECMAScript and skip a number if that's the case. If the next update is small and incremental this analogy will hold: ES 5th ed = PHP 5.4 ES harmony = PHP 7 If the next update is quite big and breaks backwards compatibility in some ways, go directly to 7. This is written from a customer perspective. I am a PHP user and educator, not a code contributor to internals. But please listen anyway. We are the ones who will get confused, and we are the majority of all people who use your product. We are your customers ;-) -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 as we know it suddenly died?
On 03/12/2010 01:40 PM, Keryx Web wrote: If the next update is quite big and breaks backwards compatibility in some ways, go directly to 7. Yes, I hope others get over the version-fobia too. :) We can't call the new (soon to be?) trunk PHP 6. Calling it 5.4 is not working either considering the bigger changes required. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
Jani Taskinen schrieb: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? It is doable, likely desired but it is going to be a bit of work. What you save is the work of having to update multiple branches manually. What you risk is that not each and every test is prepared for being run with every version - although, maybe, in theory it should be. This is certainly something that can be solved by adding some more magic to run-tests.php, e.g. ==SKIP-VERSION== as suggested by Hannes - practicalities. Also, you may end up shipping the same huge set of tests for every PHP version regardless if all tests you ship are compatible with that version. Again, some magic should solve that - practicalities. There is one thing I fear, although it is desired to do. Many extensions link external libraries. If you throw all tests in one place and run all tests with all PHP versions, I strongly assume you'll get more reports on test failures. That is because the likeliness of someone out there running new tests designed for the latest version of an external library against an old library will increase. Yes, you want to know about any such incompatibility. Yes, it helps you making your software better. But it may mean significantly more work in particular if you follow the common paragidma of test ample must always be green at any time on every system. What may cure the extra work problem is to be more strict on compatible versions. I am aware how much people love BC. But there's a point where keeping BC should be left as an exercise to those asking for BC. All in all, I like the idea but I fear extra work. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On Fri, Mar 12, 2010 at 2:04 AM, Pierre Joye pierre@gmail.com wrote: hi, On Thu, Mar 11, 2010 at 6:22 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: Ah, Jani went a little crazy today in his typical style to force a decision. The real decision is not whether to have a version 5.4 or not Jani is passionate, and that's a good thing. WRT a 5.4, we can stay on the 5.X tree forever. Why not 5.194? Why not 5.196187? If there's a 6.X tree, if there's a 6.X change, we need to have a 6 reason that is clear. See the 4-5 transitions (along with mail logs, etc.) for background. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On 03/11/2010 11:41 PM, Christopher Jones wrote: Ilia Alshanetsky wrote: +1. I think we need we need to make HEAD a common use branch where most of the developers trees are at and current HEAD iteration is just not it. I'm +1. Jani's recent 5.3 changes should be reverted, PHP_5_4 rebranched again, and then the fixes/features merged to the new branch. I have reverted the PHP_5_3 changes. Now only thing left is renaming (moving) trunk to some branch and renaming (moving) PHP_5_4 to trunk? Or are we still at the committee state? :D As to what to do with PHP_5_2 or PHP_5_3, that should be the concern of their RMs. IMO, 5.2 is in bugfix mode, so only bugfixes go there anyway. As to 5.3, that should get into bugfix mode only as well, and all development and such concentrated in trunk. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 12.03.2010 12:37, Jani Taskinen wrote: Some tests however are not supposed to work in earlier releases, so we need to either add a new ==SKIP-VERSION== 5.2, 5.1, 5.0 Perhaps something like required min version is better. Imo you need both V.E.R, V.E.R for version stuff, since you have to test for feature that disappeared or are scheduled for removal, and others that are not there yet. But any case skipping versions is not a good approach since you'd have to update it every time a new major release is made for old tests. Cheers, Jordi signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Tests repository
On 03/12/2010 01:48 PM, Ulf Wendel wrote: Jani Taskinen schrieb: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? What you save is the work of having to update multiple branches manually. Not only update, don't forget the maintaining of them. What you risk is that not each and every test is prepared for being run with every version - although, maybe, in theory it should be. This is It should not be theory for regression tests? If new release does not pass the old tests but the old versions still do, then it's quite likely the new version is buggy? Now we have different versions of same tests in each branch (in the worst cases) and thus the behaviour might really be different between them when it should not be. Also, you may end up shipping the same huge set of tests for every PHP version regardless if all tests you ship are compatible with that version. Again, some magic should solve that - practicalities. It's still one package for all. Thus less work, less space..? :) There is one thing I fear, although it is desired to do. Many extensions link external libraries. If you throw all tests in one place and run all tests with all PHP versions, I strongly assume you'll get more reports on test failures. That is because the likeliness of someone out there running new tests designed for the latest version of an external library against an old library will increase. This part I didn't quite understand..isn't this same issue with the current situation as well? versions. I am aware how much people love BC. But there's a point where keeping BC should be left as an exercise to those asking for BC. The BC is our holy grail. And having been bitten by this myself sometimes in last 3 years, I rather be a bit anal about BC now than I was before. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
Jani Taskinen schrieb: What you risk is that not each and every test is prepared for being run with every version - although, maybe, in theory it should be. This is It should not be theory for regression tests? If new release does not pass the old tests but the old versions still do, then it's quite likely the new version is buggy? Now we have different versions of same tests in each branch (in the worst cases) and thus the behaviour might really be different between them when it should not be. I am with you on the idea of a central repository and the arguments behind your two questions. Though, you know, I'm lazy and I fear you really find issues that need to be fixed :-) . For a transition period there's likely to be more work and the number of test failures is likely to go up. That is nothing to really worry about as long as you manage to educate users that it is not a quality defect of PHP as such but a temporary matter of an different and improved testing approach. There is one thing I fear, although it is desired to do. Many extensions link external libraries. If you throw all tests in one place and run all tests with all PHP versions, I strongly assume you'll get more reports on test failures. That is because the likeliness of someone out there running new tests designed for the latest version of an external library against an old library will increase. This part I didn't quite understand..isn't this same issue with the current situation as well? Its only a diffuse feeling of mine, I could well be wrong. In any case I am not trying to argue against your proposal. Just the opposite. Let's assume the worst case status quo of different versions of the same test in each branch. The one in an old branch has been written with the versions of the external library in mind that has been current when the branch was current. The one in a current branch has been written against the latest version of the external library. I continue to assume that users of the old PHP branch run rather old systems whereas users of a current PHP branch run on current systems. Therefore only few people may have tried to run the old test against the latest library or the other way around. It is just a feeling that your proposal will implicitly cause some combinations of PHP version x test x external library version to be tested that have not been checked before. Your one test for all proposal is likely to unveil some different versions of the same test and external library is not BC issues. That's good. But its gonna be work... Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/branches/
On Fri, Mar 12, 2010 at 3:38 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: imho jani's commit access should be revoked until we have sorted out our release plan for the future, because he has shown that he has no patience to respect other people's opinions and so we can alleviate him of doing stupid things to release his anxiety. but i guess i am just being a rule loving german here .. or am i just the only one with enough guts to say this? +1, until everything is in place. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
Lester Caine wrote: Currently maintaining the 5.2 branch is essential until such time as all extensions are available in official builds of PHP on windows! Forcing projects to change their development platforms simply to support a blinkered set of rules on PHP is not helpful in moving the project forward. How many extensions are currently stable in 5.2 on windows but not supported in 5.3? Private builds of the extensions in 5.3 are running without problems but having to direct users to other sites is as bad as the current fragmentation in the core code? Nobody is arguing against maintaining 5.2 for the near-mid future. If you want Windows binaries, start building . . . . Chris -- Email: christopher.jo...@oracle.comTel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/branches/
where did that mail come from? imho it should have been addressed to the mailing list directly. I agree that he was short-tempered, but I think that the progress worth it. Tyrael On Fri, Mar 12, 2010 at 3:43 PM, Pierre Joye pierre@gmail.com wrote: On Fri, Mar 12, 2010 at 3:38 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: imho jani's commit access should be revoked until we have sorted out our release plan for the future, because he has shown that he has no patience to respect other people's opinions and so we can alleviate him of doing stupid things to release his anxiety. but i guess i am just being a rule loving german here .. or am i just the only one with enough guts to say this? +1, until everything is in place. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.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: [PHP-DEV] PHP 6
On Fri, Mar 12, 2010 at 9:35 AM, Lester Caine les...@lsces.co.uk wrote: Ferenc Kovacs wrote: if you mentioned windows builds, whats the current status of http://pecl4win.php.net/ ? Also only available for PHP5.2 ;) I mean when will be avaiable, the current situation sucks for the developers who prefer working on windows (I know, shame on me). ( If you must top post TRIM :( ) sorry, gmail makes me lazy(auto indent, and default top posting) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
I'd love to see my brand-new mbstring implementation in the release. Dropping mbstring completely won't be any good because lots of applications rely on it, but I don't really want to maintain the funky library bundled with it. Moriyoshi On Fri, Mar 12, 2010 at 2:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: Ah, Jani went a little crazy today in his typical style to force a decision. The real decision is not whether to have a version 5.4 or not, it is all about solving the Unicode problem. The current effort has obviously stalled. We need to figure out how to get development back on track in a way that people can get on board. We knew the Unicode effort was hugely ambitious the way we approached it. There are other ways. So I think Lukas and others are right, let's move the PHP 6 trunk to a branch since we are still going to need a bunch of code from it and move development to trunk and start exploring lighter and more approachable ways to attack Unicode. We have a few already. Enhanced mbstring and ext/intl. Let's see some good ideas around that and work on those in trunk. Other features necessarily need to play along with these in the same branch. I refuse to go down the path of a 5.4 branch and a separate Unicode branch again. The main focus here needs to be to get everyone working in the same branch. -Rasmus -- 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] PHP 6
On Fri, Mar 12, 2010 at 5:12 PM, Christopher Jones christopher.jo...@oracle.com wrote: Nobody is arguing against maintaining 5.2 for the near-mid future. If you want Windows binaries, start building . . . . You should replace the PECL extensions for Windows is being worked on. The interface on the pecl website will most likely be updated to offer Windows DLL download right from that website. In the meantime, some extensions can be found here. message to this line on http://windows.php.net/ o_O Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On Fri, Mar 12, 2010 at 5:12 PM, Christopher Jones christopher.jo...@oracle.com wrote: Lester Caine wrote: Currently maintaining the 5.2 branch is essential until such time as all extensions are available in official builds of PHP on windows! Forcing projects to change their development platforms simply to support a blinkered set of rules on PHP is not helpful in moving the project forward. How many extensions are currently stable in 5.2 on windows but not supported in 5.3? Private builds of the extensions in 5.3 are running without problems but having to direct users to other sites is as bad as the current fragmentation in the core code? Nobody is arguing against maintaining 5.2 for the near-mid future. If you want Windows binaries, start building . . . . No need to, there were two missing, firebird and smnp. Smnp is back, firebird will likely be as well in 5.3.3 (thanks to Marius work). -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
Christopher Jones wrote: Lester Caine wrote: Currently maintaining the 5.2 branch is essential until such time as all extensions are available in official builds of PHP on windows! Forcing projects to change their development platforms simply to support a blinkered set of rules on PHP is not helpful in moving the project forward. How many extensions are currently stable in 5.2 on windows but not supported in 5.3? Private builds of the extensions in 5.3 are running without problems but having to direct users to other sites is as bad as the current fragmentation in the core code? Nobody is arguing against maintaining 5.2 for the near-mid future. If you want Windows binaries, start building . . . . I already do ;) And provide a build of PHP5.3 to go with apache on x64 windows, but it's not an official build -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository (was: Re: [PHP-DEV] PHP 6)
On Mar 12, 2010, at 5:33 AM, Pierre Joye wrote: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? BC tests and easiness are two of the reasons why we have a donwloadable phpt packages on the windows download pages. Some changes / improvements are of course needed for the run-tests.php but IIRC, someone was rewriting it already? Can we use this svn link/external somehow? Having one module for the tests but you get them when checking out a php-src branch. Gwynne can certainly answer this question :) Yes, this is quite possible. It's not quite as clean and smooth as CVS' modules support was, which is a continuing source of annoyance to me about SVN, but it's not too terribly painful either. Just the usual svn:externals properly on the php-src branches pointing to whereever the tests end up will do nicely. For the record, my standing: PHP 5.4: -1 PHP 6: -1 PHP 7 with new Unicode stuff: +1 -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 as we know it suddenly died?
Keryx Web rašė: 2. If so, what will happen to array access in strings that are de facto Unicode? Will the more clunky mb_substr() be the only option? What will happen to array access in unicode strings, if code wants to access them in bytes? Will some backwards incompatible binary be the only option? You want unicode strings. I want backwards compatibility which goes further than php 5.2.1. I want to write bytes in hexadecimal notation. I need both unicode aware and byte based functions. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
Is that new implementation in trunk already? Is it (or will it be) backwards compatible with the current one? --Jani On 03/12/2010 06:38 PM, Moriyoshi Koizumi wrote: I'd love to see my brand-new mbstring implementation in the release. Dropping mbstring completely won't be any good because lots of applications rely on it, but I don't really want to maintain the funky library bundled with it. Moriyoshi On Fri, Mar 12, 2010 at 2:22 AM, Rasmus Lerdorfras...@lerdorf.com wrote: Ah, Jani went a little crazy today in his typical style to force a decision. The real decision is not whether to have a version 5.4 or not, it is all about solving the Unicode problem. The current effort has obviously stalled. We need to figure out how to get development back on track in a way that people can get on board. We knew the Unicode effort was hugely ambitious the way we approached it. There are other ways. So I think Lukas and others are right, let's move the PHP 6 trunk to a branch since we are still going to need a bunch of code from it and move development to trunk and start exploring lighter and more approachable ways to attack Unicode. We have a few already. Enhanced mbstring and ext/intl. Let's see some good ideas around that and work on those in trunk. Other features necessarily need to play along with these in the same branch. I refuse to go down the path of a 5.4 branch and a separate Unicode branch again. The main focus here needs to be to get everyone working in the same branch. -Rasmus -- 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] PHP 6
On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi m...@mozo.jp wrote: I'd love to see my brand-new mbstring implementation in the release. Dropping mbstring completely won't be any good because lots of applications rely on it, but I don't really want to maintain the funky library bundled with it. Thats actually one of the ideas we had on IRC. That mbstring patch and more ext/intl features should be enough to solve the unicode problem. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
Hi! Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be Yes, but: some tests are version-dependant, some are not. And since we have this output match testing paradigm, it would probably keep being this way. If you're going to have branches in that SVN, how it would be different from what we have now? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 03/12/2010 08:08 PM, Stanislav Malyshev wrote: Hi! Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be Yes, but: some tests are version-dependant, some are not. And since we That's why we'd need to add some section to select the minimum version required to run the test. have this output match testing paradigm, it would probably keep being this way. If you're going to have branches in that SVN, how it would be different from what we have now? Considering what I said above about version check..why would you need branches in it? And what/how does it matter what the tests output if it needs to be same in any PHP version anyway..? The word repository was bad choice. The idea is just to have shared tests. Perhaps that makes it more clear? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 03/12/2010 04:15 PM, Ulf Wendel wrote: For a transition period there's likely to be more work and the number of test failures is likely to go up. That is nothing to really worry about as long as you manage to educate users that it is not a quality defect of PHP as such but a temporary matter of an different and improved testing approach. I'd say it's more work since some tests do not exists in some branch. As we might soon have quite closely related 3 branches, such differences are quite small. As trunk would have exactly same tests as PHP_5_3 has, the real differences would be only with PHP_5_2. So if we want such common tests, I think the time to do it is about now. Let's assume the worst case status quo of different versions of the same test in each branch. The one in an old branch has been written with the versions of the external library in mind that has been current when the branch was current. The one in a current branch has been written against the latest version of the external library. I continue to assume that users of the old PHP branch run rather old systems whereas users of a current PHP branch run on current systems. Therefore only few people may have tried to run the old test against the latest library or the other way around. It is just a feeling that your proposal will implicitly cause some combinations of PHP version x test x external library version to be tested that have not been checked before. So you actually fear that you'd have to fix some things in older branches too? Well, I think (hope) such cases are rare and such problems actually already exist too. Of course we can always stay with the status quo, but is that really good for PHP in general? Your one test for all proposal is likely to unveil some different versions of the same test and external library is not BC issues. That's good. But its gonna be work... IMO, such work is never a waste. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
Hi! That's why we'd need to add some section to select the minimum version required to run the test. How minimum version would help? If 5.2 requires one test, 5.3 another and trunk another - you either have to have 3 tests or declare that only thing you're testing is trunk (which is obviously a very bad idea). Considering what I said above about version check..why would you need branches in it? And what/how does it matter what the tests output if it needs to be same in any PHP version anyway..? It doesn't need to be the same now. Actually, for a lot of tests it isn't, for one reason or another (mostly error messages and stuff like that now, but there's more). -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On Fri, 12 Mar 2010, Hannes Magnusson wrote: On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi m...@mozo.jp wrote: I'd love to see my brand-new mbstring implementation in the release. Dropping mbstring completely won't be any good because lots of applications rely on it, but I don't really want to maintain the funky library bundled with it. Thats actually one of the ideas we had on IRC. That mbstring patch and more ext/intl features should be enough to solve the unicode problem. Sorry, but that is not true. intl and mbstring can provide functionality to deal with UTF 8 string manipulation functions, they can not provide proper Unicode support. Proper Unicode support is *not* only just dealing with UTF-8 strings. Proper Unicode support includes dealing with file streams, with different encodings, with localiztion, with sorting, with locales, with formatting numbers. Offloading this to extensions makes Unicode support an add-on hack, and not a language feature. I am not saying that intl and mbstring aren't *useful*, but they definitely do not solve the unicode problem. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On Fri, Mar 12, 2010 at 19:29, Stanislav Malyshev s...@zend.com wrote: Hi! Thats actually one of the ideas we had on IRC. That mbstring patch and more ext/intl features should be enough to solve the unicode problem. That depends on your definition of unicode problem. Original definition AFAIK was that you shouldn't care about the encodings anymore and all Unicode stuff (dbs, filesystems, output) will be supported, but it seems to be harder than we thought. Yeah. We tried it, and it simply didn't pan out (performance, bc, lost interest, ..). As long as we provide the developers with necessary tools to support it, there shouldn't be any problem. Those who want to be blissfully unaware of unicode, can. Those who want to invest time in making sure their application can handle it, can. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
Hi! Yeah. We tried it, and it simply didn't pan out (performance, bc, lost interest, ..). I think it is a bit premature to declare the death of Unicode in PHP. Yes, we know there are problems, and yes, it was harder that initially thought, so we may want to take a step back and rethink it. Also we may want to get Unicode out of the way of other PHP development, since it's taking longer than planned. But that doesn't mean we should bury it. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Fri, Mar 12, 2010 at 7:14 PM, Jani Taskinen jani.taski...@iki.fi wrote: On 03/12/2010 08:08 PM, Stanislav Malyshev wrote: Hi! Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be Yes, but: some tests are version-dependant, some are not. And since we That's why we'd need to add some section to select the minimum version required to run the test. have this output match testing paradigm, it would probably keep being this way. If you're going to have branches in that SVN, how it would be different from what we have now? Considering what I said above about version check..why would you need branches in it? And what/how does it matter what the tests output if it needs to be same in any PHP version anyway..? What you describe may work for PHP core features without external dependencies but will fail for anything with external dependencies. Many tests fail because they are written for a given platform, or even worst (from a portability point of view), only for a given configuration (library version, system version,etc.). And that's not about windows vs other, tests can work on a Debian/ubuntu version and fail on another. However the idea of shared tests is what I've been adovocating for some time already, to improve portability and BC checks. It requires to write true unit tests, and huge test including dozen of cases being tested in one test. It will also require to rewite many tests to output something when it fails instead of testing standard outpout with system dependent messages (think about localization too, which can affect behaviors as well). All in all I lilke the idea and will support it as much as I can. We have to keep in mind that it will need a couple of testfests to realize it(read: huge work, more like doing it from scratch for 40-60% of the existing test, rough estimation). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 12.03.2010, at 22:06, Pierre Joye wrote: Many tests fail because they are written for a given platform, or even worst (from a portability point of view), only for a given configuration (library version, system version,etc.). And that's not about windows vs other, tests can work on a Debian/ubuntu version and fail on another. Well, these tests should just be removed/rewritten. Php-tests should test php, not libraries -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On Mar 12, 2010, at 10:46 AM, Stanislav Malyshev wrote: Hi! Yeah. We tried it, and it simply didn't pan out (performance, bc, lost interest, ..). I think it is a bit premature to declare the death of Unicode in PHP. Yes, we know there are problems, and yes, it was harder that initially thought, so we may want to take a step back and rethink it. Also we may want to get Unicode out of the way of other PHP development, since it's taking longer than planned. But that doesn't mean we should bury it. How have other languages progressed down the unicode road? Is there anything we can learn from their progress over these past few years? Or is the problem simply lack of volunteer hours? If so, maybe a strong effort to create real internals documentation (that includes unicode goodness) a possible solution? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On Fri, Mar 12, 2010 at 19:46, Stanislav Malyshev s...@zend.com wrote: Hi! Yeah. We tried it, and it simply didn't pan out (performance, bc, lost interest, ..). I think it is a bit premature to declare the death of Unicode in PHP. Yes, we know there are problems, and yes, it was harder that initially thought, so we may want to take a step back and rethink it. Also we may want to get Unicode out of the way of other PHP development, since it's taking longer than planned. But that doesn't mean we should bury it. Sorry, it wasn't my intention to declare unicode in PHP dead. I meant to say we need to explore other options, and start smaller. Look into what we can do with the mbstring patch and expand the intl extension to cover more features would be a good first step. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin indey...@gmail.com wrote: On 12.03.2010, at 22:06, Pierre Joye wrote: Many tests fail because they are written for a given platform, or even worst (from a portability point of view), only for a given configuration (library version, system version,etc.). And that's not about windows vs other, tests can work on a Debian/ubuntu version and fail on another. Well, these tests should just be removed/rewritten. Php-tests should test php, not libraries I would be interested to know how can we test the file API without testing libc, for example. But yes, that's the idea. Redesign the tests in a way that we output something when the results of the test is not what was expected, instead of testing random outputs from random libraries (in various versions and flavours). No big change in run-tests (none?) but a lot of necessary changes in existing tests. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 12.03.2010, at 22:20, Stanislav Malyshev wrote: Hi! Well, these tests should just be removed/rewritten. Php-tests should test php, not libraries That's easy to say - but how exactly you're going to test functionality of, say. ext/intl without testing the underlying ICU library? Well, here's the way I see it: Extensions (including ext/intl) declare their API and tests are made againt this API. No more and no less. If, for example, some error-text comes directly from underlying library and extension doesn't have control over it it shouldn't be part of API. In this case we can test that some error-text was returned but we shouldn't test for exact text-match -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 12.03.2010, at 22:23, Pierre Joye wrote: On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin indey...@gmail.com wrote: On 12.03.2010, at 22:06, Pierre Joye wrote: Many tests fail because they are written for a given platform, or even worst (from a portability point of view), only for a given configuration (library version, system version,etc.). And that's not about windows vs other, tests can work on a Debian/ubuntu version and fail on another. Well, these tests should just be removed/rewritten. Php-tests should test php, not libraries I would be interested to know how can we test the file API without testing libc, for example. see my reply to Stas. The idea is to test things which we can guarantee. If our documentation says, that function does this or that, then we should check for it and wrap system-calls in such way, that our file API always does these things or fails in strict predictable manner. And if we can't guarantee some behaviour then we should add corresponding note to documentation and we shouldn't add tests. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Fri, Mar 12, 2010 at 8:39 PM, Alexey Zakhlestin indey...@gmail.com wrote: On 12.03.2010, at 22:23, Pierre Joye wrote: On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin indey...@gmail.com wrote: On 12.03.2010, at 22:06, Pierre Joye wrote: Many tests fail because they are written for a given platform, or even worst (from a portability point of view), only for a given configuration (library version, system version,etc.). And that's not about windows vs other, tests can work on a Debian/ubuntu version and fail on another. Well, these tests should just be removed/rewritten. Php-tests should test php, not libraries I would be interested to know how can we test the file API without testing libc, for example. see my reply to Stas. The idea is to test things which we can guarantee. If our documentation says, that function does this or that, then we should check for it and wrap system-calls in such way, that our file API always does these things or fails in strict predictable manner. And if we can't guarantee some behaviour then we should add corresponding note to documentation and we shouldn't add tests. That's exactly (for part of the needs) what I describe in the 2nd part of my reply. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository (run-tests.php)
On Fri, Mar 12, 2010 at 6:37 AM, Jani Taskinen jani.taski...@iki.fi wrote: On 03/12/2010 12:29 PM, Hannes Magnusson wrote: On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taski...@iki.fi wrote: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? Thats actually a fairly good idea. Some tests however are not supposed to work in earlier releases, so we need to either add a new ==SKIP-VERSION== 5.2, 5.1, 5.0 Perhaps something like required min version is better. Any ideas who has been working on the improved test stuff? Or was that just a dream? First of all, I apologize for the subject line change, but this really is a different issue than the test repository itself. It was started by George during last years GSOC. Zoe and Stefan were also working on it after GSOC ended. Both Zoe and Stefan ran out of time and it went dormant for a bit. I contacted Zoe about the status and offered to pick it up, but I also offered to organize TestFest this year. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I really do want to do both but I can't do both at the same time as they both will be big time sinks for a part time volunteer. Solutions: 1. I continue to work on TestFest and then work on run-tests.php as soon as the TestFest load lightens up enough to allow it. 2. Someone else picks up run-tests.php and I focus solely on TestFest. 3. Someone else picks up TestFest and I focus solely on run-tests.php. My vote is option 1 as I really like both projects. But it wouldn't be fair for me to slow either down if the need for both is pressing. Eric Lee Stewart
Re: [PHP-DEV] Tests repository
Hi! That's easy to say - but how exactly you're going to test functionality of, say. ext/intl without testing the underlying ICU library? Well, here's the way I see it: Extensions (including ext/intl) declare their API and tests are made againt this API. No more and no less. It's all sounds very nice in theory, except that in practice it doesn't work this way. Different versions of the library return different data, different errors, have different conditions, etc. You can just declare half of the tests to be not API, but in fact it is, that's what people use and that's what they want to be sure that it works - just different versions of it act differently. If, for example, some error-text comes directly from underlying library and extension doesn't have control over it it shouldn't be part of API. In this case we can test that some error-text was returned but we shouldn't test for exact text-match How do you know that some text is the error and that it's the correct one and not just generic wrong library call one which is produced on any bad call? And you can't just declare that number formatting routine returns some text - it would be useless. You want very specific text. But what if some detail of that text changes for some of the test cases? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Fri, Mar 12, 2010 at 4:55 PM, Stanislav Malyshev s...@zend.com wrote: Hi! That's easy to say - but how exactly you're going to test functionality of, say. ext/intl without testing the underlying ICU library? Well, here's the way I see it: Extensions (including ext/intl) declare their API and tests are made againt this API. No more and no less. It's all sounds very nice in theory, except that in practice it doesn't work this way. Different versions of the library return different data, different errors, have different conditions, etc. You can just declare half of the tests to be not API, but in fact it is, that's what people use and that's what they want to be sure that it works - just different versions of it act differently. If, for example, some error-text comes directly from underlying library and extension doesn't have control over it it shouldn't be part of API. In this case we can test that some error-text was returned but we shouldn't test for exact text-match How do you know that some text is the error and that it's the correct one and not just generic wrong library call one which is produced on any bad call? And you can't just declare that number formatting routine returns some text - it would be useless. You want very specific text. But what if some detail of that text changes for some of the test cases? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php There are going to be some technical challenges. Some (maybe a lot) of test will need updates or rewriting. run-tests.php may need more improvements than what is already planned. Knowing this, I would still rather update run-tests.php and fix the tests, then continue to applying tests to different branches of the code base. +1 to centralize tests. Eric Lee Stewart
Re: [PHP-DEV] Tests repository
Hi! There are going to be some technical challenges. Some (maybe a lot) of test will need updates or rewriting. run-tests.php may need more improvements than what is already planned. Knowing this, I would still rather update run-tests.php and fix the tests, then continue to applying tests to different branches of the code base. I still have yet to hear *how* these tests are supposed to be updated, to work everywhere. It's very easy to say oh, we'll just fix them - but how exactly you're going to fix them if the test is supposed to do one thing in 5.2 and another in 5.3? Are you going to have 2 versions of the file? if(version) wrapping the file? Two sets of output? Check for versions before outputting data? I think it's irresponsible to take such kind of decision without actually seeing what you're going to deal with and how. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
13.3.2010 0:18, Stanislav Malyshev wrote: Hi! There are going to be some technical challenges. Some (maybe a lot) of test will need updates or rewriting. run-tests.php may need more improvements than what is already planned. Knowing this, I would still rather update run-tests.php and fix the tests, then continue to applying tests to different branches of the code base. I still have yet to hear *how* these tests are supposed to be updated, to work everywhere. It's very easy to say oh, we'll just fix them - but how exactly you're going to fix them if the test is supposed to do one thing in 5.2 and another in 5.3? Are you going to have 2 versions of What tests are you really talking about here? I thought we have regression tests in there which test that stuff does not change between versions. Such test AFAICT help us to keep stuff to work like it worked before and after some change somewhere in the related code. So there should not be any need for any updates given the tests aren't for some reason different between branches in which case they aren't really the same test anymore. Short version: if test works in 5.2 it also has to (!) work in 5.3. Otherwise the test is pointless. Can you define the case you're referring to here or are we actually talking about totally different thing? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Fri, Mar 12, 2010 at 11:33 PM, Jani Taskinen jani.taski...@sci.fi wrote: 13.3.2010 0:18, Stanislav Malyshev wrote: Hi! There are going to be some technical challenges. Some (maybe a lot) of test will need updates or rewriting. run-tests.php may need more improvements than what is already planned. Knowing this, I would still rather update run-tests.php and fix the tests, then continue to applying tests to different branches of the code base. I still have yet to hear *how* these tests are supposed to be updated, to work everywhere. It's very easy to say oh, we'll just fix them - but how exactly you're going to fix them if the test is supposed to do one thing in 5.2 and another in 5.3? Are you going to have 2 versions of What tests are you really talking about here? I thought we have regression tests in there which test that stuff does not change between versions. Such test AFAICT help us to keep stuff to work like it worked before and after some change somewhere in the related code. So there should not be any need for any updates given the tests aren't for some reason different between branches in which case they aren't really the same test anymore. Short version: if test works in 5.2 it also has to (!) work in 5.3. Otherwise the test is pointless. Can you define the case you're referring to here or are we actually talking about totally different thing? Did you read our replies? I cited two kind of tests failing even on the same version. There are also many new errors or behaviors changes between 5.2 and 5.3, some errors are based on system error messages or using the underlying libraries errors. As I said already, it is possible but the way we test things have to be rewamped. Especially the variationxyz kind of tests with dozen of cases in one single phpt, including all kind of errors, system, php, etc. That's not a small move, but a huge task which will take some months to be done. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Fri, Mar 12, 2010 at 5:39 PM, Pierre Joye pierre@gmail.com wrote: On Fri, Mar 12, 2010 at 11:33 PM, Jani Taskinen jani.taski...@sci.fi wrote: 13.3.2010 0:18, Stanislav Malyshev wrote: Hi! There are going to be some technical challenges. Some (maybe a lot) of test will need updates or rewriting. run-tests.php may need more improvements than what is already planned. Knowing this, I would still rather update run-tests.php and fix the tests, then continue to applying tests to different branches of the code base. I still have yet to hear *how* these tests are supposed to be updated, to work everywhere. It's very easy to say oh, we'll just fix them - but how exactly you're going to fix them if the test is supposed to do one thing in 5.2 and another in 5.3? Are you going to have 2 versions of What tests are you really talking about here? I thought we have regression tests in there which test that stuff does not change between versions. Such test AFAICT help us to keep stuff to work like it worked before and after some change somewhere in the related code. So there should not be any need for any updates given the tests aren't for some reason different between branches in which case they aren't really the same test anymore. Short version: if test works in 5.2 it also has to (!) work in 5.3. Otherwise the test is pointless. Can you define the case you're referring to here or are we actually talking about totally different thing? Did you read our replies? I cited two kind of tests failing even on the same version. There are also many new errors or behaviors changes between 5.2 and 5.3, some errors are based on system error messages or using the underlying libraries errors. As I said already, it is possible but the way we test things have to be rewamped. Especially the variationxyz kind of tests with dozen of cases in one single phpt, including all kind of errors, system, php, etc. That's not a small move, but a huge task which will take some months to be done. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I think specific examples (ie: a link to a 5.2 test and the corresponding 5.3 test) which are currently impossible to merge would be most beneficial at this point. I'll search for some this evening. If anyone knows of one or two off the top of their head, please provide links. Eric Lee Stewart
Re: [PHP-DEV] Tests repository
Hi! What tests are you really talking about here? I thought we have regression tests in there which test that stuff does not change between Yes, we have those. But we also have other tests, which are different between versions. should not be any need for any updates given the tests aren't for some reason different between branches in which case they aren't really the same test anymore. I'm not into paying semantic games about the meaning of the word is. Define them as different tests if you want - how that solves the problem, if you have different tests in the next version? You still have two of them, not one. Short version: if test works in 5.2 it also has to (!) work in 5.3. Otherwise the test is pointless. It's not what happens with real .phpt tests, and they are not pointless. We can spend weeks discussing how the fine theory it should be, but in practice if 5.2 outputs one thing and 5.3 another then the tests differ. Just take Zend engine tests directory - out of 511 tests 62 are different in 5.3 - more than 10%. Most of them are messages, but not only. What you're going to do with them? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
Hi! I think specific examples (ie: a link to a 5.2 test and the corresponding 5.3 test) which are currently impossible to merge would be most beneficial at this point. Do a diff between two test dirs (you can use engine tests, php main tests, etc.), get a list of different files and diff them between versions. You'll see what kind of stuff is being done in tests now and how differences arise. There are many ways to get test that is different between 5.2 and 5.3. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Sat, Mar 13, 2010 at 12:04 AM, Eric Stewart ericleestew...@gmail.com wrote: I think specific examples (ie: a link to a 5.2 test and the corresponding 5.3 test) which are currently impossible to merge would be most beneficial at this point. I'll search for some this evening. If anyone knows of one or two off the top of their head, please provide links. It is always possible to write a test for both versions (except namespace). However it requires a radical change on how we test things. Instead of testing the output of given script, we will have to add logics in a test, something similar to the classic xUnit frameworks. For example, we will have to do the error msg check inside the test instead of in run-tests which will only check the output as it does now, or even better, only OK or FAILED. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
Hi!
It is always possible to write a test for both versions (except
namespace). However it requires a radical change on how we test
things.
Instead of testing the output of given script, we will have to add
logics in a test, something similar to the classic xUnit frameworks.
For example, we will have to do the error msg check inside the test
It is possible, but that means instead of 2 trees of files you'd have
these trees distributed inside test files in a myriad of small if()s:
if(version == X) { test this error message }
elseif(version == Y) { test that error message }
else { test that another error message }
and the same for different pieces of function, etc. Why is it better?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Fri, Mar 12, 2010 at 6:27 PM, Stanislav Malyshev s...@zend.com wrote:
Hi!
It is always possible to write a test for both versions (except
namespace). However it requires a radical change on how we test
things.
Instead of testing the output of given script, we will have to add
logics in a test, something similar to the classic xUnit frameworks.
For example, we will have to do the error msg check inside the test
It is possible, but that means instead of 2 trees of files you'd have these
trees distributed inside test files in a myriad of small if()s:
if(version == X) { test this error message }
elseif(version == Y) { test that error message }
else { test that another error message }
and the same for different pieces of function, etc. Why is it better?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
There are going to be differences, that's a given and I don't dispute that.
If I'm given the choice of those differences being in one file or in three
different files (5.2, 5.3, 6.0)? I choose one file. Even if that files is
more complex. It's still one file. One commit. One place to look for
problems. And you get the bonus of being able to see the actual differences
of the same functionality in different versions of PHP all in one place.
So yes, I do think that is better.
Eric Lee Stewart
Re: [PHP-DEV] Tests repository
On Sat, Mar 13, 2010 at 12:27 AM, Stanislav Malyshev s...@zend.com wrote:
Hi!
It is always possible to write a test for both versions (except
namespace). However it requires a radical change on how we test
things.
Instead of testing the output of given script, we will have to add
logics in a test, something similar to the classic xUnit frameworks.
For example, we will have to do the error msg check inside the test
It is possible, but that means instead of 2 trees of files you'd have these
trees distributed inside test files in a myriad of small if()s:
if(version == X) { test this error message }
elseif(version == Y) { test that error message }
else { test that another error message }
and the same for different pieces of function, etc. Why is it better?
I'm not saying it is better to write test, but it is better to
maintain one set of tests for all branches and keep them uptodate. But
that's definitivelly more work, and not only for the 1st shot. That's
why I would rather triple check if we really want to go down this way.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Fri, Mar 12, 2010 at 06:53:49PM -0500, Eric Stewart wrote: If I'm given the choice of those differences being in one file or in three different files (5.2, 5.3, 6.0)? I choose one file. Even if that files is more complex. It's still one file. One commit. One place to look for problems. And you get the bonus of being able to see the actual differences of the same functionality in different versions of PHP all in one place. Agreed. It seems we'll need not only a ==VERSION== section of some sort, but a ==VERSION_OUTPUT== type of thing as well. For example, when things get deprecated. The test suite needs to ensure that the function works normally in 5.2 but throws a deprecated warning in 5.3. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository (run-tests.php)
On Fri, Mar 12, 2010 at 22:18, Eric Stewart ericleestew...@gmail.com wrote: On Fri, Mar 12, 2010 at 6:37 AM, Jani Taskinen jani.taski...@iki.fi wrote: On 03/12/2010 12:29 PM, Hannes Magnusson wrote: On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taski...@iki.fi wrote: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? Thats actually a fairly good idea. Some tests however are not supposed to work in earlier releases, so we need to either add a new ==SKIP-VERSION== 5.2, 5.1, 5.0 Perhaps something like required min version is better. Any ideas who has been working on the improved test stuff? Or was that just a dream? First of all, I apologize for the subject line change, but this really is a different issue than the test repository itself. It was started by George during last years GSOC. Zoe and Stefan were also working on it after GSOC ended. Both Zoe and Stefan ran out of time and it went dormant for a bit. I contacted Zoe about the status and offered to pick it up, but I also offered to organize TestFest this year. Write up a description and post it again on http://wiki.php.net/gsoc ? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC - class underloading -or- ancestor overloading
Perhaps a new concept in class-based OO programming, I'm not sure.
Depending on your perspective you could call it ancestor overloading (or
upstream overloading) or class underloading.
We are increasingly developing with the aid of frameworks libraries. In
fact, this idea came from my current project using the Zend Framework.
These libraries, while greatly extensible, are also fairly self-extending.
That is, they include many classes that extend many classes, which is great.
As consumers of these libraries, we can extend the classes and consume the
API however we please, but there is one sticking point.
We cannot change classes that many other classes extend without extending or
changing each child class and then making sure that our code uses the new
class.
For a concrete example, I was working with the Zend_Form_Element subclasses,
and I realized that I wanted to change some of the default behavior (in
Zend_Form_Element).
- at this point I will assume the reader understands why I wouldn't want to
just start changing the Zend library files -
There are many subclasses of Zend_Form_Element. If you want to change the
default behavior for all of them, you have 3 choices currently:
1. Directly edit the Zend_Form_Element file in the library, -bad for updates
other projects that use the library
2. subclass Zend_Form_Element and change declaration of the descendants to
extend new class - same problems
3. extend each child class and implement those subclasses in your app code
-very tedious and TONS of repeated code, breaks consistency of API for
developers.
There could be a better way, if we could insert a class into the family
tree.
And that's the heart of this idea, so I'll repeat it:
* insert a class into the family tree *
Image we do it using an alternative keyword to extends, such as
overloads.
Example:
class Library_Class { }
class Library_Subclass extends Library_Class {}
and then:
class My_LibClass_Overload overloads Library_Class{}
Now new instances of Library_Subclass actually extend My_LibClass_Overload,
which extends Library_Class. The developer would then code
My_LibClass_Overload as if it were declared like this:
class Library_Class {}
class My_LibClass_Overload extends Library_Class {}
class Library_Subclass extends My_LibClass_Overload {}
But indeed the declaration of Library_Subclass would *not* have to change.
This way developers could extend default functionality and have *existing*
library classes pick up the new functionality without redeclaring anything
in the library.
Downstream classes would still override any methods that they redeclare. If
you wanted to have end-point classes in the library have different behavior,
you would overload them instead, such as
class My_LibSubclass_Overload overloads Lib_Subclass {}
The benefit is that the application code can still consume standard
classes, such as Library_Subclass and not need to know or care about the
extended functionality.
Going back to my concrete example, my code could then still use
Zend_Form_Element_Text, but benefit from the modifications I added, without
me having to touch the library code.
I hope I've explained clearly what this could look like. I'm a younger
developer, so forgive me if I'm rough on the terminology -perhaps
overload/underload is not the best word for this functionality. Also, I'm
not sure if there are other class-based OO languages that allow this kind of
behavior... Prototypal languages perhaps, as is the case with javascript and
the Obj.prototype which (combined with anonymous functions) allows you to
extend the base functionality of other objects that extend it.
Thank you for your comments and thoughts!
Chris Trahey
Web Applications Developer
Database Administrator
CSISD [Technology]
footnote: I sent this message from a different address and it did not show
up. I tested sending to internals-h...@lists.php.net and did not get a
response -so I assume there is an outgoing issue on my other server's side.
Forgive me if this message shows up again.
Re: [PHP-DEV] RFC - class underloading -or- ancestor overloading
Hi,
On Sat, Mar 13, 2010 at 2:50 AM, Chris Trahey christra...@gmail.com wrote:
Perhaps a new concept in class-based OO programming, I'm not sure.
Depending on your perspective you could call it ancestor overloading (or
upstream overloading) or class underloading.
We are increasingly developing with the aid of frameworks libraries. In
fact, this idea came from my current project using the Zend Framework.
These libraries, while greatly extensible, are also fairly self-extending.
That is, they include many classes that extend many classes, which is great.
As consumers of these libraries, we can extend the classes and consume the
API however we please, but there is one sticking point.
We cannot change classes that many other classes extend without extending or
changing each child class and then making sure that our code uses the new
class.
For a concrete example, I was working with the Zend_Form_Element subclasses,
and I realized that I wanted to change some of the default behavior (in
Zend_Form_Element).
- at this point I will assume the reader understands why I wouldn't want to
just start changing the Zend library files -
There are many subclasses of Zend_Form_Element. If you want to change the
default behavior for all of them, you have 3 choices currently:
1. Directly edit the Zend_Form_Element file in the library, -bad for updates
other projects that use the library
2. subclass Zend_Form_Element and change declaration of the descendants to
extend new class - same problems
3. extend each child class and implement those subclasses in your app code
-very tedious and TONS of repeated code, breaks consistency of API for
developers.
There could be a better way, if we could insert a class into the family
tree.
And that's the heart of this idea, so I'll repeat it:
* insert a class into the family tree *
Image we do it using an alternative keyword to extends, such as
overloads.
Example:
class Library_Class { }
class Library_Subclass extends Library_Class {}
and then:
class My_LibClass_Overload overloads Library_Class{}
Now new instances of Library_Subclass actually extend My_LibClass_Overload,
which extends Library_Class. The developer would then code
My_LibClass_Overload as if it were declared like this:
class Library_Class {}
class My_LibClass_Overload extends Library_Class {}
class Library_Subclass extends My_LibClass_Overload {}
But indeed the declaration of Library_Subclass would *not* have to change.
This way developers could extend default functionality and have *existing*
library classes pick up the new functionality without redeclaring anything
in the library.
Downstream classes would still override any methods that they redeclare. If
you wanted to have end-point classes in the library have different behavior,
you would overload them instead, such as
class My_LibSubclass_Overload overloads Lib_Subclass {}
The benefit is that the application code can still consume standard
classes, such as Library_Subclass and not need to know or care about the
extended functionality.
Going back to my concrete example, my code could then still use
Zend_Form_Element_Text, but benefit from the modifications I added, without
me having to touch the library code.
I hope I've explained clearly what this could look like. I'm a younger
developer, so forgive me if I'm rough on the terminology -perhaps
overload/underload is not the best word for this functionality. Also, I'm
not sure if there are other class-based OO languages that allow this kind of
behavior... Prototypal languages perhaps, as is the case with javascript and
the Obj.prototype which (combined with anonymous functions) allows you to
extend the base functionality of other objects that extend it.
Even though it might look appealing from a framework user perspective,
it looks fishy from a language design perspective. It sounds like
you're trying to fix a framework design lack by a language trick.
For the fishy part: what happens to the old class? what about static
method calls on that old class? What if two classes overwrites the
same class? Basically it would mean there is no way to know at compile
time which class new Foo; is supposed to instantiate.
Thank you for your comments and thoughts!
Chris Trahey
Web Applications Developer
Database Administrator
CSISD [Technology]
footnote: I sent this message from a different address and it did not show
up. I tested sending to internals-h...@lists.php.net and did not get a
response -so I assume there is an outgoing issue on my other server's side.
Forgive me if this message shows up again.
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - class underloading -or- ancestor overloading
The old class is still there, think of it as if the inserted (overloading)
class extends the base (overloaded) class and any classes the were extending
the base now extend the inserted class. So as far as the runtime, it's
run-of-the-meill inheritance. Methods that are not re-implimented in the
inserted class are called in the original class, etc.
It could be implemented either at the time a class is loaded (when we see
'overloads' keyword) or perhaps in a function call:
overload_class('Library_Class', 'My_LibClass_Overload');
As for conflicts where multiple overloads are attempted, they could be in
sequence, such that you'd end up having an inheritance chain like this:
called_class -- second_overload -- first_overload -- Library_Class --
etc.
On Fri, Mar 12, 2010 at 8:11 PM, Etienne Kneuss col...@php.net wrote:
Hi,
On Sat, Mar 13, 2010 at 2:50 AM, Chris Trahey christra...@gmail.com
wrote:
Perhaps a new concept in class-based OO programming, I'm not sure.
Depending on your perspective you could call it ancestor overloading (or
upstream overloading) or class underloading.
We are increasingly developing with the aid of frameworks libraries. In
fact, this idea came from my current project using the Zend Framework.
These libraries, while greatly extensible, are also fairly
self-extending.
That is, they include many classes that extend many classes, which is
great.
As consumers of these libraries, we can extend the classes and consume
the
API however we please, but there is one sticking point.
We cannot change classes that many other classes extend without extending
or
changing each child class and then making sure that our code uses the new
class.
For a concrete example, I was working with the Zend_Form_Element
subclasses,
and I realized that I wanted to change some of the default behavior (in
Zend_Form_Element).
- at this point I will assume the reader understands why I wouldn't want
to
just start changing the Zend library files -
There are many subclasses of Zend_Form_Element. If you want to change the
default behavior for all of them, you have 3 choices currently:
1. Directly edit the Zend_Form_Element file in the library, -bad for
updates
other projects that use the library
2. subclass Zend_Form_Element and change declaration of the descendants
to
extend new class - same problems
3. extend each child class and implement those subclasses in your app
code
-very tedious and TONS of repeated code, breaks consistency of API for
developers.
There could be a better way, if we could insert a class into the family
tree.
And that's the heart of this idea, so I'll repeat it:
* insert a class into the family tree *
Image we do it using an alternative keyword to extends, such as
overloads.
Example:
class Library_Class { }
class Library_Subclass extends Library_Class {}
and then:
class My_LibClass_Overload overloads Library_Class{}
Now new instances of Library_Subclass actually extend
My_LibClass_Overload,
which extends Library_Class. The developer would then code
My_LibClass_Overload as if it were declared like this:
class Library_Class {}
class My_LibClass_Overload extends Library_Class {}
class Library_Subclass extends My_LibClass_Overload {}
But indeed the declaration of Library_Subclass would *not* have to
change.
This way developers could extend default functionality and have
*existing*
library classes pick up the new functionality without redeclaring
anything
in the library.
Downstream classes would still override any methods that they redeclare.
If
you wanted to have end-point classes in the library have different
behavior,
you would overload them instead, such as
class My_LibSubclass_Overload overloads Lib_Subclass {}
The benefit is that the application code can still consume standard
classes, such as Library_Subclass and not need to know or care about the
extended functionality.
Going back to my concrete example, my code could then still use
Zend_Form_Element_Text, but benefit from the modifications I added,
without
me having to touch the library code.
I hope I've explained clearly what this could look like. I'm a younger
developer, so forgive me if I'm rough on the terminology -perhaps
overload/underload is not the best word for this functionality. Also, I'm
not sure if there are other class-based OO languages that allow this kind
of
behavior... Prototypal languages perhaps, as is the case with javascript
and
the Obj.prototype which (combined with anonymous functions) allows you to
extend the base functionality of other objects that extend it.
Even though it might look appealing from a framework user perspective,
it looks fishy from a language design perspective. It sounds like
you're trying to fix a framework design lack by a language trick.
For the fishy part:
[PHP-DEV] SVN Account Request: ariva
Fixing bugs, developing the PHP runtime, can contribute ~10h/w -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Fri, Mar 12, 2010 at 9:52 PM, Pierre Joye pierre@gmail.com wrote
On Sat, Mar 13, 2010 at 12:27 AM, Stanislav Malyshev s...@zend.com wrote:
Hi!
It is possible, but that means instead of 2 trees of files you'd have these
trees distributed inside test files in a myriad of small if()s:
if(version == X) { test this error message }
elseif(version == Y) { test that error message }
else { test that another error message }
and the same for different pieces of function, etc. Why is it better?
I'm not saying it is better to write test, but it is better to
maintain one set of tests for all branches and keep them uptodate. But
that's definitivelly more work, and not only for the 1st shot. That's
why I would rather triple check if we really want to go down this way.
One thing to notice is change in output between versions.
During testfest we wrote various tests and tried to make them as
generic as possible to run in 5.2/5.3/6.
It worked in mosts tests but some suttle differences would make it a
pain to write a unified test.
For example: When writing the tests for trunk string became unicode
Whatever path PHP6 does go down, we need to rememebr small changes
like this can come along in other aspects
So just a version check for the test is not all that's needed, we need
something to deal with these differences as well.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - class underloading -or- ancestor overloading
On Mar 12, 2010, at 9:28 PM, Chris Trahey wrote:
The old class is still there, think of it as if the inserted (overloading)
class extends the base (overloaded) class and any classes the were extending
the base now extend the inserted class. So as far as the runtime, it's
run-of-the-meill inheritance. Methods that are not re-implimented in the
inserted class are called in the original class, etc.
It could be implemented either at the time a class is loaded (when we see
'overloads' keyword) or perhaps in a function call:
overload_class('Library_Class', 'My_LibClass_Overload');
As for conflicts where multiple overloads are attempted, they could be in
sequence, such that you'd end up having an inheritance chain like this:
called_class -- second_overload -- first_overload -- Library_Class --
etc.
In Objective-C, one did this in the older days by calling NSObject's
-poseAsClass: method, which would replace the class you sent it to with the
class you specified. Nowadays that approach is strongly discouraged in favor of
method swizzling, a technique by which you replace a specific class'
implementation of a single method with your own (which, with a minor bit of
extra work, can call through to the original). Internally, it's done by
replacing the function pointer in the class' method table with a new one and
returning the old one. Zend's implementation is slightly more twisted than
libobjc's, amusingly enough, but it's still doable. This is the typical way for
a dynamic language to solve the problem you've described. In PHP I believe the
necessary work is already implemented in runkit via the function
runkit_method_redefine(). You need only install that, or refer to it to make an
extension of your own. If you want this functionality in core, file a feature
request. (I'm personally in favor of making a lot of runkit's dynamic class
tweaking abilities core).
As far as I understand your issue, this technique would solve it cleanly.
On Fri, Mar 12, 2010 at 8:11 PM, Etienne Kneuss col...@php.net wrote:
Hi,
On Sat, Mar 13, 2010 at 2:50 AM, Chris Trahey christra...@gmail.com
wrote:
Perhaps a new concept in class-based OO programming, I'm not sure.
Depending on your perspective you could call it ancestor overloading (or
upstream overloading) or class underloading.
We are increasingly developing with the aid of frameworks libraries. In
fact, this idea came from my current project using the Zend Framework.
These libraries, while greatly extensible, are also fairly
self-extending.
That is, they include many classes that extend many classes, which is
great.
As consumers of these libraries, we can extend the classes and consume
the
API however we please, but there is one sticking point.
We cannot change classes that many other classes extend without extending
or
changing each child class and then making sure that our code uses the new
class.
For a concrete example, I was working with the Zend_Form_Element
subclasses,
and I realized that I wanted to change some of the default behavior (in
Zend_Form_Element).
- at this point I will assume the reader understands why I wouldn't want
to
just start changing the Zend library files -
There are many subclasses of Zend_Form_Element. If you want to change the
default behavior for all of them, you have 3 choices currently:
1. Directly edit the Zend_Form_Element file in the library, -bad for
updates
other projects that use the library
2. subclass Zend_Form_Element and change declaration of the descendants
to
extend new class - same problems
3. extend each child class and implement those subclasses in your app
code
-very tedious and TONS of repeated code, breaks consistency of API for
developers.
There could be a better way, if we could insert a class into the family
tree.
And that's the heart of this idea, so I'll repeat it:
* insert a class into the family tree *
Image we do it using an alternative keyword to extends, such as
overloads.
Example:
class Library_Class { }
class Library_Subclass extends Library_Class {}
and then:
class My_LibClass_Overload overloads Library_Class{}
Now new instances of Library_Subclass actually extend
My_LibClass_Overload,
which extends Library_Class. The developer would then code
My_LibClass_Overload as if it were declared like this:
class Library_Class {}
class My_LibClass_Overload extends Library_Class {}
class Library_Subclass extends My_LibClass_Overload {}
But indeed the declaration of Library_Subclass would *not* have to
change.
This way developers could extend default functionality and have
*existing*
library classes pick up the new functionality without redeclaring
anything
in the library.
Downstream classes would still override any methods that they redeclare.
If
you wanted to have end-point classes in the library have different
behavior,
you would overload them
Re: [PHP-DEV] PHP 6
Huh? mbstring has been capable of handling lots of encodings other than UTF-8 since it was introduced. We might often find it annoying that Unicode is handled transparently through I/O functions when the internal encoding is different from the outside encoding. It just seems you didn't ever make a serious internaltionalized application. Moriyoshi On Sat, Mar 13, 2010 at 3:34 AM, Derick Rethans der...@php.net wrote: On Fri, 12 Mar 2010, Hannes Magnusson wrote: On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi m...@mozo.jp wrote: I'd love to see my brand-new mbstring implementation in the release. Dropping mbstring completely won't be any good because lots of applications rely on it, but I don't really want to maintain the funky library bundled with it. Thats actually one of the ideas we had on IRC. That mbstring patch and more ext/intl features should be enough to solve the unicode problem. Sorry, but that is not true. intl and mbstring can provide functionality to deal with UTF 8 string manipulation functions, they can not provide proper Unicode support. Proper Unicode support is *not* only just dealing with UTF-8 strings. Proper Unicode support includes dealing with file streams, with different encodings, with localiztion, with sorting, with locales, with formatting numbers. Offloading this to extensions makes Unicode support an add-on hack, and not a language feature. I am not saying that intl and mbstring aren't *useful*, but they definitely do not solve the unicode problem. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: ariva
You contribute some patches first to internals and after that's been done a few times we give out an SVN account. Scott On 12 Mar 2010, at 19:01, Arunas Ivanauskas arunas.ivanaus...@gmail.com wrote: Fixing bugs, developing the PHP runtime, can contribute ~10h/w -- 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
