Greetings Internals
I've been thinking for a while what we should do about PHP6 and its
future, because right now it seems like there isn't much future in it.
PHP6 is already much different in terms of the current coverage, many
merges to HEAD seems like non unicode compliant versions. Meaning even
more work needs to be done to get it on a somewhat stable level than
it already is. I think we should if possible focus abit more on it,
and if it needs it then consider stopping the 5.2 branch so only 5.3 +
HEAD is under active development. I can see that Andrei is listed as
RM on the wiki, and I know that the unicode engine is his baby, but
I'm unsure whether he actually is else we should find one who is
willing to push PHP6 more now that its been very quite since
2005/2006.
What I propose is that we need to do an evaluation of the status, and
write up a milestone for an, lets say alpha 1 that only focuses on
Unicode, the API and coverage and fixing general merges that haven't
found place. Say our Alpha 1 TODO was like this:
- Clean up
- Move extensions to PECL before unicode coverage
- Move new extensions into the core before unicode coverage
- Remove legacy code if any left like safe_mode, etc. and other
deprecated features - Merge missing fixes if any
- Unicode, Unicode, Unicode
- Finish the API/Engine
- Review all the current covered functions with help from the QA team
to make sure the tests passes as expected - Coverage at, say 60% or similar so its at 100% by stable release
What I'm trying to say here is that if we could focus on finishing the
unicode part and stuff like clean ups by the very beginning we don't
have to wait for an API to be converted to unicode so X, Z or Y
feature can be made possible, or bug FOO, BAR and BAZ fixed.
I know its a huge work as it is now, but if we don't start focusing on
PHP6 then we could just as re-branch 5.3 to trunk and merge eventual
improvements to it, which I honestly think would be such a waste.
After the first milestone is done, we can try focus / look at
implementing the very discussed features like:
- Type hinting
- Traits
- etc.
(PS. Please don't turn this thread into a some heavy debate about the
implementations of these, its just examples of what could be
implemented)
But what is every ones input on the matter of attempting to boost
PHP6's development? I'm willing to give my part in whatever I can to
help getting up on the feet to get this ball rolling.
--
regrads,
Kalle Sommer Nielsen
kalle@php.net
Hello,
But what is every ones input on the matter of attempting to boost
PHP6's development? I'm willing to give my part in whatever I can to
help getting up on the feet to get this ball rolling.
I think that some more focus on PHP6 would be great! Though I am not
sure if 5.2 could stop development (although perhaps a resource shift
to 5.3/6, starving new 5.2 features/backports for 5.2 security/bug
fixes only). I would hate to see PHP6 become P(erl)HP6 :p
Chris Stockton wrote:
Hello,
But what is every ones input on the matter of attempting to boost
PHP6's development? I'm willing to give my part in whatever I can to
help getting up on the feet to get this ball rolling.I think that some more focus on PHP6 would be great! Though I am not
sure if 5.2 could stop development (although perhaps a resource shift
to 5.3/6, starving new 5.2 features/backports for 5.2 security/bug
fixes only). I would hate to see PHP6 become P(erl)HP6 :p
I have the same feeling on 5.2. While I'm very happy with PHP 5.3
(especially with the addition of closures), it takes a nontrivial amount
of work to migrate a web app from PHP 5.2 to 5.3.
The PHP 5.3 compatibility issue for the Drupal CMS
(http://drupal.org/node/360605), for example, had over 200 comments, and
it took about 9 months before a patch was committed to the current
version of Drupal in September (see comment 158). That's not the only
example, but it's a prominent one that comes to my mind.
It makes sense to shift resources, but it's way too soon IMHO to stop
doing security and bug fixes for 5.2.
Hi!
The PHP 5.3 compatibility issue for the Drupal CMS
(http://drupal.org/node/360605), for example, had over 200 comments, and
it took about 9 months before a patch was committed to the current
version of Drupal in September (see comment 158). That's not the only
example, but it's a prominent one that comes to my mind.
it looks like their issues were primarily caused by:
- Relying on exact text of error messages
- Using runtime by-ref passing (which one definitely shouldn't do)
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Those things were already deprecated, it's good thing that php 5.3
finally broke bad code, php 5 (since the first alpha) is there since a
while, drupal is drupal if folks don't want to fix it, what's the big
deal there? just pach it yourself it's open source isn't it? so
nothing stop you to fork, what's the matter with the language
implementation internal-list seriously drupal I don't care, drupal is
not php and won't decide for keeping legacy support or not, so
complain to drupal team not here
Hi!
The PHP 5.3 compatibility issue for the Drupal CMS
(http://drupal.org/node/360605), for example, had over 200 comments, and
it took about 9 months before a patch was committed to the current
version of Drupal in September (see comment 158). That's not the only
example, but it's a prominent one that comes to my mind.it looks like their issues were primarily caused by:
- Relying on exact text of error messages
- Using runtime by-ref passing (which one definitely shouldn't do)
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
beware, troll.
Tyrael
Those things were already deprecated, it's good thing that php 5.3
finally broke bad code, php 5 (since the first alpha) is there since a
while, drupal is drupal if folks don't want to fix it, what's the big
deal there? just pach it yourself it's open source isn't it? so
nothing stop you to fork, what's the matter with the language
implementation internal-list seriously drupal I don't care, drupal is
not php and won't decide for keeping legacy support or not, so
complain to drupal team not hereHi!
The PHP 5.3 compatibility issue for the Drupal CMS
(http://drupal.org/node/360605), for example, had over 200 comments, and
it took about 9 months before a patch was committed to the current
version of Drupal in September (see comment 158). That's not the only
example, but it's a prominent one that comes to my mind.it looks like their issues were primarily caused by:
- Relying on exact text of error messages
- Using runtime by-ref passing (which one definitely shouldn't do)
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Kalle Sommer Nielsen wrote:
But what is every ones input on the matter of attempting to boost
PHP6's development? I'm willing to give my part in whatever I can to
help getting up on the feet to get this ball rolling.
Hi,
As someone who has successfully ported a rather complex extension (phar)
to PHP 6 compatibility, and in the process found and fixed a serious bug
in the core stuff for converting from and to unicode, I can say with
some authority that this is a huge job.
Fortunately, even though it's huge I think the task is far simpler than
deciding on a roadmap. All of the core functionality already exists
(check out the README.UNICODE* files to see how it works). We also have
.phpt tests for just about everything thanks to testfest.
What needs to happen is for developers to focus on finding problems
highlighted by failing .phpt tests. The most complex extension that
needs some loving is the SPL extension. I would hazard a guess that if
these .phpt tests are fixed, a large number of roadblocks will disappear.
So, if you want to fix PHP 6, setup gdb (or if you'd a GUI dweeb like
me, ddd), and start fixing spl .phpt tests, and then move on to the
other extensions.
Once these tests pass, it will then be possible to talk more roadmappy.
I should also point out that the memory leaks at the end of building PHP
6 when phar.phar is created were introduced by my bugfix because the fix
involved adding an emalloc()ed pointer that must be freed. I think some
of the oldest code relies upon the old behavior and doesn't free it, so
if these can be found, it will get rid of the leak. The bug I fixed
manifested itself with a random crash when running the .phpt tests, and
was seriously hard to isolate, so please don't revert my fix unless you
know what you're doing :).
Greg
What needs to happen is for developers to focus on finding problems
highlighted by failing .phpt tests. The most complex extension that
needs some loving is the SPL extension. I would hazard a guess that if
these .phpt tests are fixed, a large number of roadblocks will disappear.
AFAIK PDO is also in a very broken state, though independently of PHP6 I am currently hoping to revitalize PDO development, which might also lead to building up the necessary resources/skills to get HEAD fixed up too.
Anyways, to me it boils down to 2-3 people really putting in lots of time to move things forward and to build up momentum again. We all know how it feels to add stuff onto something that is fairly broken and who's future is not yet certain. We all hate wasting time, so those 2-3 people will mostly reassure that time spend on HEAD is not wasted.
In this light when I last brought up this topic. Not sure if on IRC or the mailinglist it turned out that 3 different approaches were seen by people. Again who ever takes the helm on this will hopefully realign the community behind just one:
- similar to Kalle's suggestion, clean up HEAD
- make HEAD a proof of concept branch, turn 5_3 into HEAD, reimplement just the features we in the end found useful from HEAD
- make HEAD a proof of concept branch, turn 5_3 into HEAD, implement a string class (both a unicode and a non unicode version) along the lines of the intl extension to bring unicode functionality to PHP but in a way that lets people easily switch between unicode aware strings.
I think I remember that 2) got the least support. Ilia was the main one argueing in favor of 3) and Derick was very much pro 1). I am putting this out there not because I am looking forward to a lengthy discussion on this, but more because I feel that who ever takes on this task should know that there are different opinions on how to best proceed. In the end however I think that who ever does the work will probably get the biggest say in how things play out ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org