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
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.
+1 for moving trunk to a branch and moving 5.3 to trunk.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
+1 for moving trunk to a branch and moving 5.3 to trunk.
not moving 5.3 to trunk but a 5.3 copy (branched of), 5.3 should be
stable stuff (fixes) only. Guess you meant to say that, but better to be
clear.
johannes
+1 for moving trunk to a branch and moving 5.3 to trunk.
not moving 5.3 to trunk but a 5.3 copy (branched of), 5.3 should be
stable stuff (fixes) only. Guess you meant to say that, but better to be
clear.
err exactly. thx for clarifying :)
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
11.3.2010 19:54, Johannes Schlüter wrote:
+1 for moving trunk to a branch and moving 5.3 to trunk.
not moving 5.3 to trunk but a 5.3 copy (branched of), 5.3 should be
stable stuff (fixes) only. Guess you meant to say that, but better to be
clear.
How about just moving PHP_5_4 to trunk and leave (after revert..) the PHP_5_3
where it is.
--Jani
11.3.2010 19:22, Rasmus Lerdorf wrote:
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.
So it's just the name? Sorry, should have been more imaginative with that branch
name. So what you're proposing is simply matter of renaming stuff. Rename trunk
to branches/THIS_IS_LOST_CAUSE (or whatever) and PHP_5_4 to trunk. And we're a
go. I really don't see reason to ditch current PHP_5_3 however, just to keep
something to release stable stuff from..
The main focus here needs to be to get everyone working in the same branch.
The main focus should be that we actually start working. And not wait for
someone to do something miraculous on their own. I'm just sick and tired of the
cloak and dagger style and secret meetings and committees. So please, do the
talking openly on the mailing list, not some IRC channels. And no more wikis. :)
--Jani
The main focus should be that we actually start working. And not wait for someone to do something miraculous on their own. I'm just sick and tired of the cloak and dagger style and secret meetings and committees. So please, do the talking openly on the mailing list, not some IRC channels. And no more wikis. :)
i hope you mean internals and not the svn commit mailinglist. so much for dagger style ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
The main focus should be that we actually start working. And not wait
for someone to do something miraculous on their own. I'm just sick and
tired of the cloak and dagger style and secret meetings and committees.
So please, do the talking openly on the mailing list, not some IRC
channels. And no more wikis. :)
I haven't been to any cloak-and-dagger meetings in years. And haven't
said a word on irc about it. So I am not sure what you are talking about.
-Rasmus
+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.
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
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'd also like to see us start a slow deprioritization of 5.2 work.
Instead effort should go into making 5.3 the prefered stable branch.
One specific example is that Test Fest 2010 tests shouldn't be merged
to 5.2.
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
--
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/UGPOM
On Thu, Mar 11, 2010 at 4:41 PM, Christopher Jones <
christopher.jones@oracle.com> 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'd also like to see us start a slow deprioritization of 5.2 work.
Instead effort should go into making 5.3 the prefered stable branch.
One specific example is that Test Fest 2010 tests shouldn't be merged
to 5.2.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
--
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book:
http://tinyurl.com/UGPOM--
Focusing TestFest on 5.3 was not how I had envisioned TestFest 2010, I was
operating under the assumption we would be committing all applicable tests
to 5.2, 5.3 and 6.0 as was done last year. Focusing strictly on 5.3
certainly makes my job (and others working on TestFest 2010) easier but I
wasn't aware that anyone was even entertaining this.
This is obviously not strictly on point with this discussion and I don't
think a divergence from the main topic is appropriate at this moment. But it
underscores the importance that we will be much better off hashing this out
sooner rather than later as things in the near future will certainly bear
significant effects.
As this thread winds down and consensus is reached, I'll bring this
particular topic up again on the QA List with a discussion based on results
of late events.
Eric Lee Stewart
Eric Stewart wrote:
Focusing TestFest on 5.3 was not how I had envisioned TestFest 2010, I was
operating under the assumption we would be committing all applicable tests
to 5.2, 5.3 and 6.0 as was done last year. Focusing strictly on 5.3
certainly makes my job (and others working on TestFest 2010) easier but I
wasn't aware that anyone was even entertaining this.This is obviously not strictly on point with this discussion and I don't
think a divergence from the main topic is appropriate at this moment. But it
underscores the importance that we will be much better off hashing this out
sooner rather than later as things in the near future will certainly bear
significant effects.As this thread winds down and consensus is reached, I'll bring this
particular topic up again on the QA List with a discussion based on results
of late events.Eric Lee Stewart
I think they should be merged to 5.3 and trunk (which is the "branch"
I really meant in my previous email, not 5.4).
Looking at e.g. the DBA tests, I am building with 3 different versions
of the Berkeley DB client library. With OCI8 tests I build with three
different client libraries and then test against three different DB
versions. Repeating this kind of effort for 5.2 at this mature stage
of its life isn't worthwhile use of resources IMHO (when no code has
changed). In a perfect world we'd do it, but where we are now I think
we need to focus the efforts of testers on 5.3+.
Chris
--
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/UGPOM
Even though the 5.2 code base is fairly mature, it is far from being bug
free. Unit tests are often a good way to identify corner cases that may
not be handled properly even in the stable branches, so more tests IMHO
is a good thing. Until the decision is made to discontinue the 5.2
branch, which should be done eventually, maybe even later this year, we
should not neglect it from any standpoint, especially tests.
Eric Stewart wrote:
Focusing TestFest on 5.3 was not how I had envisioned TestFest 2010,
I was
operating under the assumption we would be committing all applicable
tests
to 5.2, 5.3 and 6.0 as was done last year. Focusing strictly on 5.3
certainly makes my job (and others working on TestFest 2010) easier
but I
wasn't aware that anyone was even entertaining this.This is obviously not strictly on point with this discussion and I
don't
think a divergence from the main topic is appropriate at this
moment. But it
underscores the importance that we will be much better off hashing
this out
sooner rather than later as things in the near future will certainly
bear
significant effects.As this thread winds down and consensus is reached, I'll bring this
particular topic up again on the QA List with a discussion based on
results
of late events.Eric Lee Stewart
I think they should be merged to 5.3 and trunk (which is the "branch"
I really meant in my previous email, not 5.4).Looking at e.g. the DBA tests, I am building with 3 different versions
of the Berkeley DB client library. With OCI8 tests I build with three
different client libraries and then test against three different DB
versions. Repeating this kind of effort for 5.2 at this mature stage
of its life isn't worthwhile use of resources IMHO (when no code has
changed). In a perfect world we'd do it, but where we are now I think
we need to focus the efforts of testers on 5.3+.Chris
Even though the 5.2 code base is fairly mature, it is far from being bug
free. Unit tests are often a good way to identify corner cases that may
not be handled properly even in the stable branches, so more tests IMHO
is a good thing. Until the decision is made to discontinue the 5.2
branch, which should be done eventually, maybe even later this year, we
should not neglect it from any standpoint, especially tests.
I don't think we should force merging in 5.2, Chris madea good point
about proper testing of tests with external systems/libs.
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.
johannes
Eric Stewart wrote:
Focusing TestFest on 5.3 was not how I had envisioned TestFest 2010,
I was
operating under the assumption we would be committing all applicable
tests
to 5.2, 5.3 and 6.0 as was done last year. Focusing strictly on 5.3
certainly makes my job (and others working on TestFest 2010) easier
but I
wasn't aware that anyone was even entertaining this.This is obviously not strictly on point with this discussion and I
don't
think a divergence from the main topic is appropriate at this
moment. But it
underscores the importance that we will be much better off hashing
this out
sooner rather than later as things in the near future will certainly
bear
significant effects.As this thread winds down and consensus is reached, I'll bring this
particular topic up again on the QA List with a discussion based on
results
of late events.Eric Lee Stewart
I think they should be merged to 5.3 and trunk (which is the "branch"
I really meant in my previous email, not 5.4).Looking at e.g. the DBA tests, I am building with 3 different versions
of the Berkeley DB client library. With OCI8 tests I build with three
different client libraries and then test against three different DB
versions. Repeating this kind of effort for 5.2 at this mature stage
of its life isn't worthwhile use of resources IMHO (when no code has
changed). In a perfect world we'd do it, but where we are now I think
we need to focus the efforts of testers on 5.3+.Chris
2010/3/11 Johannes Schlüter johannes@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.
johannes
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.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Ilia Alshanetsky wrote:
Even though the 5.2 code base is fairly mature, it is far from being bug
free. Unit tests are often a good way to identify corner cases that may
not be handled properly even in the stable branches, so more tests IMHO
is a good thing. Until the decision is made to discontinue the 5.2
branch, which should be done eventually, maybe even later this year, we
should not neglect it from any standpoint, especially tests.
Hi Ilia,
We should start a change of mind-set soon and I look forward to you
coordinating & broadcasting a rough timeline for the 5.2 release
schedule.
To be clear for the record, I'm very much in favor of having PHP well
tested. And fixes of course should still go to 5.2.
Once you decide a release schedule for the last few PHP 5.2 releases,
the criteria for accepting bug fixes should get stricter and stricter
as the terminal release approaches. In my mind, tests are at the
other end of the spectrum from security fixes. The testfest tests
might possibly not get merged to SVN until later in the year, by which
time the criteria for inclusion in PHP 5.2 should be different to that
of today.
P.S. I look forward to you merging tests for
http://svn.php.net/viewvc?view=revision&revision=295731
http://svn.php.net/viewvc?view=revision&revision=294335 etc
Chris (feeling like he's crossed to Pierre's/Jani's corner of the ring
with the above PS.)
Eric Stewart wrote:
Focusing TestFest on 5.3 was not how I had envisioned TestFest 2010,
I was
operating under the assumption we would be committing all applicable
tests
to 5.2, 5.3 and 6.0 as was done last year. Focusing strictly on 5.3
certainly makes my job (and others working on TestFest 2010) easier
but I
wasn't aware that anyone was even entertaining this.This is obviously not strictly on point with this discussion and I
don't
think a divergence from the main topic is appropriate at this
moment. But it
underscores the importance that we will be much better off hashing
this out
sooner rather than later as things in the near future will certainly
bear
significant effects.As this thread winds down and consensus is reached, I'll bring this
particular topic up again on the QA List with a discussion based on
results
of late events.Eric Lee Stewart
I think they should be merged to 5.3 and trunk (which is the "branch"
I really meant in my previous email, not 5.4).Looking at e.g. the DBA tests, I am building with 3 different versions
of the Berkeley DB client library. With OCI8 tests I build with three
different client libraries and then test against three different DB
versions. Repeating this kind of effort for 5.2 at this mature stage
of its life isn't worthwhile use of resources IMHO (when no code has
changed). In a perfect world we'd do it, but where we are now I think
we need to focus the efforts of testers on 5.3+.Chris
--
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/UGPOM
Hi!
I'd also like to see us start a slow deprioritization of 5.2 work.
Instead effort should go into making 5.3 the prefered stable branch.
One specific example is that Test Fest 2010 tests shouldn't be merged
to 5.2.
I agree with you on 5.3 in general but I think having more tests in 5.2
wouldn't hurt anybody. If there are people willing to do this work, why
not? It's not the code, so it has no risk, just the reward...
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
I'd also like to see us start a slow deprioritization of 5.2 work.
Instead effort should go into making 5.3 the prefered stable branch.
One specific example is that Test Fest 2010 tests shouldn't be merged
to 5.2.I agree with you on 5.3 in general but I think having more tests in 5.2
wouldn't hurt anybody. If there are people willing to do this work, why
not? It's not the code, so it has no risk, just the reward...
If test festers want to run their 5.3 tests with PHP 5.2 binary then
great! It might find some compatibility issues and these should be
bugged. But cleaning up the tests to work with 5.2 is something that
should not be a "must have" requirement for this year's testfest.
I'd prefer their willing work was put into deeper 5.3 & trunk testing.
Chris
--
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/UGPOM
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
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
Hannes Magnusson 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.0or 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
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
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.0Perhaps 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
On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taskinen@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.0Perhaps something like required min version is better.
Any ideas who has been working on the improved test stuff? Or was
that just a dream?
I'd rather just check for whether a feature exists or not, rather than
hard-coding version numbers in tests. For example, hat happens if the
PHP 5.3/6 case repeats itself, with more and more being backported? Do
we need to go through and change skip-version metadata on hundreds of
tests? Could we not just check that, e.g., "get_called_class" exists?
With such feature testing (in skipif?) we could just do something
along the lines of:
---FILE---
<?php
if (version_compare(PHP_VERSION, '5.3', '>=') &&
function_exists('get_called_class'))
echo 'PASS';
elseif (version_compare(PHP_VERSION, '5.3', '<') && !
function_exists('get_called_class'))
echo 'PASS';
else
echo 'FAIL';
?>
--EXPECTF--
PASS
Then, through the magic of logic, we would be guaranteed to have the
right results for each version if all tests pass, and only one place
to change when backporting/removing a feature.
-g
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
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
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
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
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 isIt 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
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 beYes, 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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 beYes, 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
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
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?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
Well, these tests should just be removed/rewritten.
Php-tests should test php, not librariesThat'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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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-matchHow 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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com--
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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 ofWhat 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
On Fri, Mar 12, 2010 at 11:33 PM, Jani Taskinen jani.taskinen@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 ofWhat 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
--
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 testIt 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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com--
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
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 testIt 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
On Fri, Mar 12, 2010 at 9:52 PM, Pierre Joye pierre.php@gmail.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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 ofWhat 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?
I recently wrote a patch for DOMDocument::saveHTML which made a test
from 5.3 start failing: it expected there was no first argument,
triggering an error when one was provided. I, in changing the function
to mirror DOMDocument::saveXML, made this fail by adding a node
argument: if we cannot even add functionality to where we currently
trigger errors, then we can do very little to the language.
For the subset of tests which are /not/ testing errors are thrown, I
entirely agree, we should just change behaviour of code that does not
currently throw errors. But we have tests for more than just that. We
have tests that check errors are thrown in cases, and those tests we
should be able to change at will.
--
Geoffrey Sneddon
<http://gsnedders.com/
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
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 librariesI 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.
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 librariesI 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
On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin
indeyets@gmail.com 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 librariesI 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.
To prefix the following comment: I've spent the previous six months
working full-time on Opera's new ECMAScript (i.e., JavaScript) engine,
and have spent a fair bit of time looking at ECMAScript test suites.
I'm somewhat doubtful about how we can ever test PHP that well: by and
large PHP-the-language is defined by PHP-the-interpreter; as long as
this is the case, how can a test have a pass/fail condition: the
interpreter is by definition correct as it is the definition of the
language you are testing?
To take an example from ECMAScript, Math.sin is defined as, "Returns
an implementation-dependent approximation to the sine of x. The
argument is expressed in radians." This is followed by a definition
which defines exact return values for the case of the argument being
±0, ±Inf, or NaN. The intention of the ECMAScript spec saying such a
thing is /exactly/ that of using system libraries: it is designed so
that you can use whatever the sin function of the maths library you
are using returns.
In the PHP manual, sin is defined as, "sin() returns the sine of the
arg parameter. The arg parameter is in radians." This is similar, but
contains one vital difference: the PHP function says it returns the
exact sine (or, at the very least, does not permit any variation
from it). If the PHP interpreter is to actually follow the manual in
this case, it is pretty much impossible for it to use any system
library, as they could easily vary from the value of sine, which the
manual does not permit.
If nothing else, I think PHP testing would become a lot easier if we
had some clear specification of what PHP was actually expected to
do. At the moment, all there is to go by is what is in the manual
(almost always far too vague to actually exhaustively test) and what
the implementation itself does (and it's never a good situation to be
working out what the implementation /should/ do from what it actually
does).
The first thing that needs to be done with a lot of tests that fail on
certain platforms currently within PHP is work out what result is
expected, and that is currently almost impossible for the above
reasons. I don't see how we can make any large gains in testing until
we have some clear way of knowing what behaviour is expected.
I'm certainly willing to help spec out more of PHP to the extent
necessary to be able to decently test it, if there is interest in
doing so.
--
Geoffrey Sneddon
<http://gsnedders.com/
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
+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.
That's my oppinion as well. Trunk should be a common development
branch. Once we decide to do a release, we choose a set of features we
like to have (not 300 hundred like in 5.3) so we can have manageable
release cycles (yearly?). That's something I've been willing to
propose for some time already and I know that other like to do that as
well.
More generally about 5.4 or not, it is still premature, even if I like
the idea (if kept small).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
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
hi,
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.
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.
-
Are you proposing that unicode strings disappear?
-
If so, what will happen to array access in strings that are de facto
Unicode? Will the more clunkymb_substr()be the only option? -
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/
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
Keryx Web rašė:
- If so, what will happen to array access in strings that are de facto
Unicode? Will the more clunkymb_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
2010-03-12 18:36, Tomas Kuliavas skrev:
Keryx Web rašė:
- If so, what will happen to array access in strings that are de
facto Unicode? Will the more clunkymb_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.
Yours is a power user request, mine is a concern for the newbies.
PHP has gotten to where it is because it has been easy to pick up and
new users will feel productive from day one.
I can say with 100 % certainty that new users will be SEVERELY confused
if they use array access and get individual bytes from a multibyte
encoded string.
Easy defaults for the newcomers and power tools for power users is a
much better approach than the other way around.
To all:
I note that my question is still unanswered.
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/
To all:
I note that my question is still unanswered.
Ask again in a year. We simply do not know.
-Hannes
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
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
Is that new implementation in trunk already? Is it (or will it be)
backwards compatible with the current one?
--Jani
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
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
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
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.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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?
From all the languages that I've had dealings with, only Python has
attempted anything like the previous PHP 6 attempt. Ruby's move to a
certain level of Unicode support in 1.9 is interesting, though I'm not
entirely sure that's been out for long enough to draw any real
conclusions about uptake of it from.
I think the most important thing learnt from the Python case is that
backwards compatibility is paramount, and trying to break backwards
compatibility with programmatic conversion to the new language version
is hard to gather uptake on, yet alone what happened with the old PHP6
branch, which would've broken large amounts of applications with no
way to programmatically convert code to it.
Python 2 had no problem getting uptake where Unicode strings need to
be specifically marked (e.g., u"foo" as opposed to "foo"), yet Python
3 (which can mostly be programmatically converted from Python 2) has
had comparatively little uptake due to its incompatibility.
So, let me start with what I want to be true of PHP 6: anything that
runs under PHP 5.3 and does not throw any errors (with E_ALL |
E_DEPRECATED) must behave identically under PHP 6.
That single statement has quite a lot of consequences, but, with
regards to Unicode, one thing more than anything else: Unicode strings
cannot be the default. I have plenty of code that uses UTF-8 in some
strings and arbitrary binary data in others. I want to be able to move
to PHP 6 gradually: I shouldn't have to wait for every library I rely
upon to be modified for PHP 6 compatibility. I should just be able to
move to PHP 6, and look over my own code and change what strings I
want to Unicode strings.
To point out what should be obvious to everyone here: one of the
biggest strengths of PHP is the large amount of library and
applications already written for it. Making a large, backwards
incompatible change such as making Unicode strings the default would
not only limit adoption to those who have entirely new code, but also
alienate most shared-hosting providers who cannot afford to break
their clients code because of a backwards incompatible change that'll
break everyone's applications.
If there's one thing I've learnt from working on browsers for the past
few years it's that backwards compatibility is more valuable than
something new and shiny. I have no doubt PHP needs Unicode support,
but I don't think that breaking backwards compatibility for it is the
right solution. The fact that PHP is deployed as it is, often in
shared hosting setups, should very much be a reason to be concerned
for backwards compatibility. A browser would get almost no marketshare
if it broke a large percentage of existing websites; I believe the
same to be true of PHP with the websites it powers.
--
Geoffrey Sneddon
<http://gsnedders.com/
On Wed, Mar 17, 2010 at 12:23 AM, Geoffrey Sneddon
foolistbar@googlemail.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.How have other languages progressed down the unicode road? Is there
anything we can learn from their progress over these past few years?From all the languages that I've had dealings with, only Python has
attempted anything like the previous PHP 6 attempt. Ruby's move to a certain
level of Unicode support in 1.9 is interesting, though I'm not entirely sure
that's been out for long enough to draw any real conclusions about uptake of
it from.I think the most important thing learnt from the Python case is that
backwards compatibility is paramount, and trying to break backwards
compatibility with programmatic conversion to the new language version is
hard to gather uptake on, yet alone what happened with the old PHP6 branch,
which would've broken large amounts of applications with no way to
programmatically convert code to it.Python 2 had no problem getting uptake where Unicode strings need to be
specifically marked (e.g., u"foo" as opposed to "foo"), yet Python 3 (which
can mostly be programmatically converted from Python 2) has had
comparatively little uptake due to its incompatibility.So, let me start with what I want to be true of PHP 6: anything that runs
under PHP 5.3 and does not throw any errors (withE_ALL| E_DEPRECATED) must
behave identically under PHP 6.That single statement has quite a lot of consequences, but, with regards to
Unicode, one thing more than anything else: Unicode strings cannot be the
default.
I would suggest making an ini setting for turning on the old behavior.
I have plenty of code that uses UTF-8 in some strings and arbitrary
binary data in others.
If you do, then you are using the binary safe functions, or the mb
extension, which case you shouldn't have a problem migrating to
unicode.
I want to be able to move to PHP 6 gradually: I
shouldn't have to wait for every library I rely upon to be modified for PHP
6 compatibility. I should just be able to move to PHP 6, and look over my
own code and change what strings I want to Unicode strings.
We don't know what will be the next version, if it will be called
anything other, than 5.x then you shouldn't be suprised, if there are
backward incompatibilities, but I agree if that shouldn't be done
without a good reason. But unicode support is a good reason.To point out what should be obvious to everyone here: one of the biggest
strengths of PHP is the large amount of library and applications already
written for it. Making a large, backwards incompatible change such as making
Unicode strings the default would not only limit adoption to those who have
entirely new code, but also alienate most shared-hosting providers who
cannot afford to break their clients code because of a backwards
incompatible change that'll break everyone's applications.
The shared hosting providers dont have to upgrade right away,
In fact:
"On May 22, 2000, PHP 4, powered by the Zend Engine 1.0, was
released.[3] As of August 2008 this branch is up to version 4.4.9.
PHP 4 is no longer under development nor will any security updates be
released.[9][10]
On July 13, 2004, PHP 5 was released, powered by the new Zend Engine II."
So for example they had 4 years after the first release of PHP5 to
tell their customers to migrate their apps to php5.
If there will be PHP6, I think it will happen just like this. If
somebody wants the new features, then he can migrate right away, the
rest slowly adopt.
If there's one thing I've learnt from working on browsers for the past few
years it's that backwards compatibility is more valuable than something new
and shiny.
IE6 & IE7 isnt backward compatible, IE8 can emulate IE7, every major
FF version did broke some bc, there are cases when you did something
wrong, and has to change/drop it.
I have no doubt PHP needs Unicode support, but I don't think that
breaking backwards compatibility for it is the right solution. The fact that
PHP is deployed as it is, often in shared hosting setups, should very much
be a reason to be concerned for backwards compatibility.
With fastcgi you can run every vhost with its own php version/php.ini
so its more secure(suexec, or mpm-itk), and they can use any supported
php version.
A browser would get
almost no marketshare if it broke a large percentage of existing websites; I
believe the same to be true of PHP with the websites it powers.
The browsers ARE incompatible, but the developers fix the issues, so
the users did not see it.
Just like as the php apps/frameworks overcome the differences of the
php versions.
You have to write portable, environment independent code, and you
shouldn't get much trouble porting it.
I hope that the shared hosting providers and they customers, who are
using 6 year old codes, wont stop the evolution of the language
itself.
Tyrael
--
Geoffrey Sneddon
<http://gsnedders.com/
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
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
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
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
Huh? mbstring has been capable of handling lots of encodings other
than UTF-8 since it was introduced.
I meant to say that mbstring does string manipulation functions, not
full unicode support.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
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".
I think unicode should only care for string handling. Formatting
numbers should not be the thing that unicode cares. Unicode is a
standard for text, not for text or number formatting.
Back to the days we don't have unicode, the number formatting have
already existed. It even exists when computer was not invented.
That is same for sorting.
When we think about Unicode, we should think about those really
related to Unicode,like file system. Number formatting and sorting are
other things which intl cares.
For the unicode, I think we should implement something like:
$chars=new mchar($bytes,$bytes_encoding);
echo $chars;//output encoding
foreach ($chars as $char) {
echo $char;//output single utf-16/utf-8 char (depends on default
output encoding)
}
echo $chars->bytes('gbk');
$chars->outputEncoding('gbk');
echo $chars;
ini_set('mchar_output_encoding','gbk');
echo $chars;
ini_set('mchar_filesystem_encoding','gbk');
echo $chars->filepath();
regards,
Derick--
--
aka Surf Chen
http://chenze.name/
Chen Ze 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".I think unicode should only care for string handling. Formatting
numbers should not be the thing that unicode cares. Unicode is a
standard for text, not for text or number formatting.Back to the days we don't have unicode, the number formatting have
already existed. It even exists when computer was not invented.That is same for sorting.
When we think about Unicode, we should think about those really
related to Unicode,like file system. Number formatting and sorting are
other things which intl cares.For the unicode, I think we should implement something like:
$chars=new mchar($bytes,$bytes_encoding);
echo $chars;//output encoding
foreach ($chars as $char) {
echo $char;//output single utf-16/utf-8 char (depends on default
output encoding)
}
echo $chars->bytes('gbk');$chars->outputEncoding('gbk');
echo $chars;ini_set('mchar_output_encoding','gbk');
echo $chars;ini_set('mchar_filesystem_encoding','gbk');
echo $chars->filepath();
I think this probably highlights the fundamental difference of opinions on Unicode?
Handling unicode CONTENT is not the problem here. People nowadays expect to be
able to use their own language to write code, and create functions using words
that they recognize. In databases, table and field names are now expected to
support unicode, rather than just handling unicode data pumped into ascii titled
fields.
Personally I'm quite happy with just using ascii names for things, but more and
more overseas customers provide contact details in 'strange' character sets that
only unicode can handle, and handling THAT in PHP5 is not a problem. It's when
people start building databases with unicode metadata and expect the tools
interfacing with that to understand unicode as well.
It was my understanding that PHP6 was intended to provide international users
with something that they could use in their own native language? Unicode titled
files with unicode titled classes and functions.
--
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
It was my understanding that PHP6 was intended to provide international
users with something that they could use in their own native language?
Unicode titled files with unicode titled classes and functions.
Please get your facts straight about the current PHP, this is
perfectly valid code that runs fine, it contains a russian class name,
chinese method name and arabic variable name.
class ѮѠф {
function 艾弗($ـجــج) {
return strtoupper($ـجــج);
}
}
$obj = new ѮѠф;
echo $obj->艾弗('test'); // outputs TEST
I attached a copy of the code in a file in case your mail client
doesn't handle unicode as good as php ;)
The PHP6 unicode support was to have unicode strings being handled
natively by all functions, for example to have strlen() working fine
on a UTF-32 encoded string while currently one must use mb_strlen() to
get the correct result.
Cheers,
Jordi
Handling unicode CONTENT is not the problem here. People nowadays expect to
be able to use their own language to write code, and create functions using
words that they recognize. In databases, table and field names are now
expected to support unicode, rather than just handling unicode data pumped
into ascii titled fields.Personally I'm quite happy with just using ascii names for things, but more
and more overseas customers provide contact details in 'strange' character
sets that only unicode can handle, and handling THAT in PHP5 is not a
problem. It's when people start building databases with unicode metadata and
expect the tools interfacing with that to understand unicode as well.It was my understanding that PHP6 was intended to provide international
users with something that they could use in their own native language?
Unicode titled files with unicode titled classes and functions.
I doubt that many people are gonna start using non-latin characters
for the identifiers, as long as most of those generally use the
alphabetic keyboard, with which I cannot type any Japanese words as
fast as alphanumerics. In addition, I think RTL languages such as
Arabic aren't supposed to use with latin punctuation marks in a
programming language in the first place.
Moriyoshi
I think unicode should only care for string handling. Formatting
numbers should not be the thing that unicode cares. Unicode is a
standard for text, not for text or number formatting.
That's a totally wrong statement. Please read Unicode specs, there are
clear references to formatting as well as many other areas. It is
impossible to split the unicode scripts from the way we process or use
them (output, formatting, sorting, searching, conversions, etc.).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I think unicode should only care for string handling. Formatting
numbers should not be the thing that unicode cares. Unicode is a
standard for text, not for text or number formatting.That's a totally wrong statement. Please read Unicode specs, there are
clear references to formatting as well as many other areas. It is
impossible to split the unicode scripts from the way we process or use
them (output, formatting, sorting, searching, conversions, etc.).
sorry, I am wrong.
I was thinking number formatting, collation as a independent standard
even many implementation(for example intl) are based on the unicode.
But I still think we should implement unicode string handling and
something like number formatting as independent interface.
For internal unicode type for function name, class name or something
others, since there is other mail talking about that, I will give my
point there.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
aka Surf Chen
http://chenze.name/
I think unicode should only care for string handling. Formatting
numbers should not be the thing that unicode cares. Unicode is a
standard for text, not for text or number formatting.Back to the days we don't have unicode, the number formatting have
already existed. It even exists when computer was not invented.That is same for sorting.
When we think about Unicode, we should think about those really
related to Unicode,like file system. Number formatting and sorting are
other things which intl cares.For the unicode, I think we should implement something like:
$chars=new mchar($bytes,$bytes_encoding);
echo $chars;//output encoding
foreach ($chars as $char) {
echo $char;//output single utf-16/utf-8 char (depends on default
output encoding)
}
echo $chars->bytes('gbk');$chars->outputEncoding('gbk');
echo $chars;ini_set('mchar_output_encoding','gbk');
echo $chars;ini_set('mchar_filesystem_encoding','gbk');
echo $chars->filepath();
I don't totally agree with what is being said here, but I guess we
don't have to make Unicode a first-class value. Once operator
overloading is supported, Unicode strings can be represented as
objects, like Python does although I didn't have a look at past
discussion on this topic.
Moriyoshi
I don't totally agree with what is being said here, but I guess we
don't have to make Unicode a first-class value. Once operator
overloading is supported, Unicode strings can be represented as
objects, like Python does although I didn't have a look at past
discussion on this topic.
Operators overloading, while being a cool feature, should not be
associated with Unicode&related features. Or we are going to do the
exact same mistakes than before, way too many changes, features, work
to even get a visible deadline for the next major release.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Surprisingly, It can be done quite easily with the current object
handler infrastructure.
Moriyoshi
I don't totally agree with what is being said here, but I guess we
don't have to make Unicode a first-class value. Once operator
overloading is supported, Unicode strings can be represented as
objects, like Python does although I didn't have a look at past
discussion on this topic.Operators overloading, while being a cool feature, should not be
associated with Unicode&related features. Or we are going to do the
exact same mistakes than before, way too many changes, features, work
to even get a visible deadline for the next major release.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
It looks like I stripped off too much. Attached is the right one.
Moriyoshi
Surprisingly, It can be done quite easily with the current object
handler infrastructure.Moriyoshi
I don't totally agree with what is being said here, but I guess we
don't have to make Unicode a first-class value. Once operator
overloading is supported, Unicode strings can be represented as
objects, like Python does although I didn't have a look at past
discussion on this topic.Operators overloading, while being a cool feature, should not be
associated with Unicode&related features. Or we are going to do the
exact same mistakes than before, way too many changes, features, work
to even get a visible deadline for the next major release.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Surprisingly, It can be done quite easily with the current object
handler infrastructure.
I don't think It is about how easy it can be done using only object
but about opening the pandora box while trying to figure out higher
priorities (and get them released).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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.
I am also in favour for getting back to one branch for new development.
And that "branch" should be trunk. However, I am a little bit reluctant
to just "kill" all Unicode support. I don't think we can get around the
fact that propr Unicode support is going to be even more important in
the future than it already is today. However, we can also not get around
the fact that the current state of "Unicode-in-PHP" isn't the most ideal
situation.
I do however think that most of the current approaches of adding Unicode
support into PHP 6 (current trunk) have the proper ideas behind that,
but I do think that in some cases we went slightly overboard of
supporting Unicode everywhere with the new "unicode" type. For example,
we don't really need to have this for variable or function names or
support every encoding for writing scripts in. (We do
need to support Unicode there, but not with the unicode string type.)
Another example is that we perhaps don't have to support every encoding
out there.
So I would suggest the following things to do:
- get rid of Jani's play branch
- move trunk to branches/FIRST_UNICODE_IDEA
- put 5.2 in security fix only mode
- pht 5.3 in bug fix only mode
- start adding new features (traits, Ilia's scalar typehint patch,
output buffering things) to the new trunk cloned from 5.3. - in the meanwhile, start working on patching in back Unicode support,
but in small steps. Exactly which things, and how we'd have to find
out. But I do think it needs to be a core language feature, and not
simply solved by extensions. We also need to make sure everybody
understands that Unicode isn't just about encodings, or charsets and
that thre are differences between that. Education is going to be
important (and adding Unicode back in small bits would certainly help
there).
As I now have plenty of time to work on things, I'd be happy to act as
RM, and wouldn't mind working on roadmaps and sorting out what good bits
we have/had, and which things we don't want to port back into the new
trunk. Depending on how things go, this could become 5.4 or 6 or
something else.
with kind regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Hi,
So I would suggest the following things to do:
- get rid of Jani's play branch
- move trunk to branches/FIRST_UNICODE_IDEA
- put 5.2 in security fix only mode
- pht 5.3 in bug fix only mode
- start adding new features (traits, Ilia's scalar typehint patch,
output buffering things) to the new trunk cloned from 5.3.- in the meanwhile, start working on patching in back Unicode support,
but in small steps. Exactly which things, and how we'd have to find
out. But I do think it needs to be a core language feature, and not
simply solved by extensions. We also need to make sure everybody
understands that Unicode isn't just about encodings, or charsets and
that thre are differences between that. Education is going to be
important (and adding Unicode back in small bits would certainly help
there).
+1
johannes
- in the meanwhile, start working on patching in back Unicode support,
but in small steps. Exactly which things, and how we'd have to find
out. But I do think it needs to be a core language feature, and not
simply solved by extensions. We also need to make sure everybody
understands that Unicode isn't just about encodings, or charsets and
that thre are differences between that. Education is going to be
important (and adding Unicode back in small bits would certainly help
there).
Unicode isn't just about a coded character set, but a whole lot of
specifications that are essential in handling various kinds of texts
within an application. But, I don't really think it reinforces the
reason Unicode functionality needs to be part of core language.
Moriyoshi
I do however think that most of the current approaches of adding Unicode
support into PHP 6 (current trunk) have the proper ideas behind that,
but I do think that in some cases we went slightly overboard of
supporting Unicode everywhere with the new "unicode" type. For example,
we don't really need to have this for variable or function names or
support every encoding for writing scripts in. (We do
need to support Unicode there, but not with the unicode string type.)
Another example is that we perhaps don't have to support every encoding
out there.
Right, dropping the current trunk doesnt mean that we should forget about unicode. However we need to find a balance between ease of use, performance (especially for those who do not need better unicode support) and release timeframe.
So I would suggest the following things to do:
- get rid of Jani's play branch
- move trunk to branches/FIRST_UNICODE_IDEA
- put 5.2 in security fix only mode
- pht 5.3 in bug fix only mode
- start adding new features (traits, Ilia's scalar typehint patch,
output buffering things) to the new trunk cloned from 5.3.
+1
As for the exact features to merge, lets first start with formulating a plan about what we want to see in the next release. I also think it makes sense to base the number and scope if the features on a rough idea of when we want to see this next release. In order to put together that release plan i guess we should have an RM defined first. I think Andi said the same thing on IRC yesterday.
I can certainly see you as RM, but i would like to propose another newer guy for the job:
David Soria Parra
That being said, I also think that the model of a co-RM that focuses on the less technical aspects as proven itself with 5.3. not only does it mean the work load is spread over two shoulders, it also means that developers can get answers quicker (especially as we are all sometimes swamped with work or god forbid go on vacation). I am willing to take the co-RM role again. I can also see Philip in this role. But I think the more important question is to find the technical RM and if the technical RM feels like he can use the support he can just appoint a co-RM.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
+1
As for the exact features to merge, lets first start with formulating a plan about what we want to see in the next release. I also think it makes sense to base the number and scope if the features on a rough idea of when we want to see this next release. In order to put together that release plan i guess we should have an RM defined first. I think Andi said the same thing on IRC yesterday.
I can certainly see you as RM, but i would like to propose another newer guy for the job:
David Soria Parra
for the record: I'm willing to do the RM. Besides my spare time that I spend on the
project I have dedicated working time for this.
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.I am also in favour for getting back to one branch for new development.
And that "branch" should be trunk. However, I am a little bit reluctant
to just "kill" all Unicode support. I don't think we can get around the
fact that propr Unicode support is going to be even more important in
the future than it already is today. However, we can also not get around
the fact that the current state of "Unicode-in-PHP" isn't the most ideal
situation.
You know I am not in favour of "killing" Unicode. We can't kill
Unicode. We live in a Unicode world, like it or not. We just need to
reset the effort and do it in smaller steps. So, setting aside the
current trunk in a branch and slowly bringing the good bits and pieces
from it into the development branch in a way that doesn't alienate
everyone should be the goal here.
- get rid of Jani's play branch
I don't think Jani has messed up anything in that branch yet, so that
could be the new trunk. It's just cloned from 5.3 exactly like you are
proposing.
As I now have plenty of time to work on things, I'd be happy to act as
RM, and wouldn't mind working on roadmaps and sorting out what good bits
we have/had, and which things we don't want to port back into the new
trunk. Depending on how things go, this could become 5.4 or 6 or
something else.
Cool, theoretically I have plenty of time right now as well, although in
practice that doesn't seem to be the case.
-Rasmus
hi,
- get rid of Jani's play branch
I don't think Jani has messed up anything in that branch yet, so that
could be the new trunk. It's just cloned from 5.3 exactly like you are
proposing.
Not exactly, there are commits done in 5.3 since the creation of this
branch. I would suggest to simply kill it, create trunk from PHP_5_3
and then Jani can merge the OB API patch again.
Cool, theoretically I have plenty of time right now as well, although in
practice that doesn't seem to be the case.
I'm in favour of David as we need fresh blood, he has no history or
conflict, very neutral on all aspects and has a very good tech
knowledge of the core as well as many extensions. He has also time to
fully assume this role. And Lukas as co-lead, for the reasons he
explained in his reply.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
As I now have plenty of time to work on things, I'd be happy to act as
RM, and wouldn't mind working on roadmaps and sorting out what good bits
we have/had, and which things we don't want to port back into the new
trunk. Depending on how things go, this could become 5.4 or 6 or
something else.
If you are proposing it and have time to do it, I think you being the
RM for the Unicode stuff (and whatever version number this is) is
going to be the only way to move the Unicode forward.
As for Lukas idea, I agree having two RMs (or co-RM) elimitates
problems we had in the past.
We need to focus on Unicode more than what some says, whether this
means descoping the Unicode release or not. However, this means that
the development focus needs to be towards new features AND Unicode,
not having the new feature branch, and the siberia branch with Unicode
support.
Anyway, might be useless email, but I'm +1 on Derick's ideas (and +10
on PHP5.2 security patches only. Some people don't even realize PHP
5.3 is out, need to move on now)
Best regards,
Olivier
-----Original Message-----
From: Olivier Hill [mailto:olivier.hill@gmail.com]
Sent: Saturday, March 13, 2010 10:15 AM
To: Derick Rethans
Cc: PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHP 6We need to focus on Unicode more than what some says, whether this
means descoping the Unicode release or not. However, this means that
the
development focus needs to be towards new features AND Unicode, not
having the new feature branch, and the siberia branch with Unicode
support.
I think the key to rebuilding momentum in PHP development is to not try
and boil the ocean but to focus on "smaller" major releases. This would
enable us to manage a more predictable release cycle, lower the risk for
each release incl. better manage compatibility and increase motivation
for contributors as they know they can have an impact and if they can't
make one release they know the next isn't that far off (the latter also
eliminates pressure to push pre-mature functionality into a release).
In that spirit I would not necessarily couple Unicode support and the
next "smaller" major version. First I would suggest to build a
well-defined, reasonably scoped list of functionality for the next drop.
I think we should make only a few features must-haves and the rest
should-haves so that only high-priority pieces of functionality can
potentially hold up a release. It also helps with quality as high risk
functionality that feels unstable could be pushed out if needed. This
encourages pushing out functionality to our users sooner rather than
later (in the realm of reason).
Then as far as Unicode support is concerned I think we need to work in
parallel on various RFCs that can provide alternative ways of
approaching the Unicode problem. Given the performance hit, memory
overhead and complexity of the current implementation (which I also
supported) I think we should try and look for a solution that is more
pragmatic and is more explicit - giving the average PHP user the same
experience, compatibility and performance characteristics of PHP 5.x
while giving the more sophisticated users who need Unicode the tools to
build global applications.
Btw, I do think we should feel comfortable to call the next major
version PHP 6 no matter what its content is (if it warrants a major
version). I think the PHP dev community should put a stake in the ground
and feel comfortable to redefine what PHP 6 is, whether it's with or
without Unicode. This isn't a Perl 6 situation. This group shipped PHP
5.3 which was a very big step-up and a quite impressive major version.
My 2 cents.
Andi
Andi Gutmans wrote:
We need to focus on Unicode more than what some says, whether this
means descoping the Unicode release or not. However, this means that
the
development focus needs to be towards new features AND Unicode, not
having the new feature branch, and the siberia branch with Unicode
support.I think the key to rebuilding momentum in PHP development is to not try
and boil the ocean but to focus on "smaller" major releases. This would
enable us to manage a more predictable release cycle, lower the risk for
each release incl. better manage compatibility and increase motivation
for contributors as they know they can have an impact and if they can't
make one release they know the next isn't that far off (the latter also
eliminates pressure to push pre-mature functionality into a release).
Please can we also put PDO back in the melting pot ... this is also still a
'pre-mature' functionality partly because of the very limited target it set, but
this has also resulted in a base that simply does not work. All of the database
drivers are getting new features which SHOULD be developed at the PDO level if
THAT is to become the standard. At present no one is working on the gaps in PDO
mainly because adding database specific features can't be handled, and therefore
projects that have switched to PDO are finding that even for MySQl and Posgresql
( the only two drivers that are reasonably stable in PDO ) they have to also
access the native drivers ...
The base class for PDO simply does not allow any chance of supporting cross
connection activities - something which is rather important as projects scale.
--
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
-----Original Message-----
From: Olivier Hill [mailto:olivier.hill@gmail.com]
Sent: Saturday, March 13, 2010 10:15 AM
To: Derick Rethans
Cc: PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHP 6We need to focus on Unicode more than what some says, whether this
means descoping the Unicode release or not. However, this means that
the
development focus needs to be towards new features AND Unicode, not
having the new feature branch, and the siberia branch with Unicode
support.I think the key to rebuilding momentum in PHP development is to not try
and boil the ocean but to focus on "smaller" major releases. This would
enable us to manage a more predictable release cycle, lower the risk for
each release incl. better manage compatibility and increase motivation
for contributors as they know they can have an impact and if they can't
make one release they know the next isn't that far off (the latter also
eliminates pressure to push pre-mature functionality into a release).
Yeah, I wouldnt mind if we would aim for regular releases in late spring early summer every year. This ensures that developers scratching their own itch have a clear timeline by when their hard work can make it into a stable release.
In that spirit I would not necessarily couple Unicode support and the
next "smaller" major version. First I would suggest to build a
well-defined, reasonably scoped list of functionality for the next drop.
I think we should make only a few features must-haves and the rest
should-haves so that only high-priority pieces of functionality can
potentially hold up a release. It also helps with quality as high risk
functionality that feels unstable could be pushed out if needed. This
encourages pushing out functionality to our users sooner rather than
later (in the realm of reason).
+1
Then as far as Unicode support is concerned I think we need to work in
parallel on various RFCs that can provide alternative ways of
approaching the Unicode problem. Given the performance hit, memory
overhead and complexity of the current implementation (which I also
supported) I think we should try and look for a solution that is more
pragmatic and is more explicit - giving the average PHP user the same
experience, compatibility and performance characteristics of PHP 5.x
while giving the more sophisticated users who need Unicode the tools to
build global applications.
+1 .. this all aligns perfectly with my suggestion to establish a "unicode working group" that I made in the "PHP 5.4 branch and trunk" thread. so just like you i agree that we shouldnt put the next release under the pressure of delivering "the unicode answer" .. if the working group gets done in time we can move it into the release plan, if not .. so it goes .. with regular releases the next chance to get unicode in isnt too far off.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
-----Original Message-----
From: Olivier Hill [mailto:olivier.hill@gmail.com]
Sent: Saturday, March 13, 2010 10:15 AM
To: Derick Rethans
Cc: PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHP 6We need to focus on Unicode more than what some says, whether this
means descoping the Unicode release or not. However, this means that
the
development focus needs to be towards new features AND Unicode, not
having the new feature branch, and the siberia branch with Unicode
support.I think the key to rebuilding momentum in PHP development is to not try
and boil the ocean but to focus on "smaller" major releases. This would
enable us to manage a more predictable release cycle, lower the risk for
each release incl. better manage compatibility and increase motivation
for contributors as they know they can have an impact and if they can't
make one release they know the next isn't that far off (the latter also
eliminates pressure to push pre-mature functionality into a release).Yeah, I wouldnt mind if we would aim for regular releases in late spring early summer every year. This ensures that developers scratching their own itch have a clear timeline by when their hard work can make it into a stable release.
yes I agree with that.
In that spirit I would not necessarily couple Unicode support and the
next "smaller" major version. First I would suggest to build a
well-defined, reasonably scoped list of functionality for the next drop.
I think we should make only a few features must-haves and the rest
should-haves so that only high-priority pieces of functionality can
potentially hold up a release. It also helps with quality as high risk
functionality that feels unstable could be pushed out if needed. This
encourages pushing out functionality to our users sooner rather than
later (in the realm of reason).+1
+1
Then as far as Unicode support is concerned I think we need to work in
parallel on various RFCs that can provide alternative ways of
approaching the Unicode problem. Given the performance hit, memory
overhead and complexity of the current implementation (which I also
supported) I think we should try and look for a solution that is more
pragmatic and is more explicit - giving the average PHP user the same
experience, compatibility and performance characteristics of PHP 5.x
while giving the more sophisticated users who need Unicode the tools to
build global applications.+1 .. this all aligns perfectly with my suggestion to establish a "unicode working group" that I made in the "PHP 5.4 branch and trunk" thread. so just like you i agree that we shouldnt put the next release under the pressure of delivering "the unicode answer" .. if the working group gets done in time we can move it into the release plan, if not .. so it goes .. with regular releases the next chance to get unicode in isnt too far off.
I agree. For sure we should keep the unicode group open and transparent,
but as andi and lukas said, we shouldn't force unicode to be inside the
next version. So people that want to work on unicode should get together
and prepare RFCs. Probably Derick and others like to help with that as
already pointed out. But the next release should be pragmatic and not
depend on things taht are very uncertain at the moment.
David
-----Original Message-----
From: Olivier Hill [mailto:olivier.hill@gmail.com]
Sent: Saturday, March 13, 2010 10:15 AM
To: Derick Rethans
Cc: PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHP 6We need to focus on Unicode more than what some says, whether this
means descoping the Unicode release or not. However, this means that
the
development focus needs to be towards new features AND Unicode, not
having the new feature branch, and the siberia branch with Unicode
support.I think the key to rebuilding momentum in PHP development is to not try
and boil the ocean but to focus on "smaller" major releases. This would
enable us to manage a more predictable release cycle, lower the risk for
each release incl. better manage compatibility and increase motivation
for contributors as they know they can have an impact and if they can't
make one release they know the next isn't that far off (the latter also
eliminates pressure to push pre-mature functionality into a release).Yeah, I wouldnt mind if we would aim for regular releases in late spring
early summer every year. This ensures that developers scratching their own
itch have a clear timeline by when their hard work can make it into a
stable release.
Two releases per year is what Ubuntu is doing and is fine for a desktop
system. Server admins (which are a large part of our target group) are
way more conservative about updating their systems all the time.
That said I generally like the Ubuntu model - having fixed release
cycles with short time supported versions (giving early access to new
features) and long time supported versions (every n-th release is
supported n short release cycles, every other release just up to the
next release)
I hold such a model actually way more interesting for contributors as
they can see their features in a timely manner after making it stable in
the wild. With the current model it can take years till a feature is
rolled out - which is frustrating for contributors.
johannes
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.I am also in favour for getting back to one branch for new development.
And that "branch" should be trunk. However, I am a little bit reluctant
to just "kill" all Unicode support. I don't think we can get around the
fact that propr Unicode support is going to be even more important in
the future than it already is today. However, we can also not get around
the fact that the current state of "Unicode-in-PHP" isn't the most ideal
situation.I do however think that most of the current approaches of adding Unicode
support into PHP 6 (current trunk) have the proper ideas behind that,
but I do think that in some cases we went slightly overboard of
supporting Unicode everywhere with the new "unicode" type. For example,
we don't really need to have this for variable or function names or
support every encoding for writing scripts in. (We do
need to support Unicode there, but not with the unicode string type.)
Another example is that we perhaps don't have to support every encoding
out there.So I would suggest the following things to do:
- get rid of Jani's play branch
- move trunk to branches/FIRST_UNICODE_IDEA
- put 5.2 in security fix only mode
- pht 5.3 in bug fix only mode
- start adding new features (traits, Ilia's scalar typehint patch,
output buffering things) to the new trunk cloned from 5.3.- in the meanwhile, start working on patching in back Unicode support,
but in small steps. Exactly which things, and how we'd have to find
out. But I do think it needs to be a core language feature, and not
simply solved by extensions. We also need to make sure everybody
understands that Unicode isn't just about encodings, or charsets and
that thre are differences between that. Education is going to be
important (and adding Unicode back in small bits would certainly help
there).As I now have plenty of time to work on things, I'd be happy to act as
RM, and wouldn't mind working on roadmaps and sorting out what good bits
we have/had, and which things we don't want to port back into the new
trunk. Depending on how things go, this could become 5.4 or 6 or
something else.with kind regards,
Derick--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug--
+1 Single Development Branch and move 6.0 branch to UNICODE_FIRST_ATTEMPT
+1 Derick RM to spearhead a more progressive approach to implementing
Unicode support.
Eric Lee Stewart
I am also in favour for getting back to one branch for new development.
And that "branch" should be trunk. However, I am a little bit reluctant
to just "kill" all Unicode support. I don't think we can get around the
fact that propr Unicode support is going to be even more important in
the future than it already is today. However, we can also not get around
the fact that the current state of "Unicode-in-PHP" isn't the most ideal
situation.I do however think that most of the current approaches of adding Unicode
support into PHP 6 (current trunk) have the proper ideas behind that,
but I do think that in some cases we went slightly overboard of
supporting Unicode everywhere with the new "unicode" type. For example,
we don't really need to have this for variable or function names or
support every encoding for writing scripts in. (We do
need to support Unicode there, but not with the unicode string type.)
Another example is that we perhaps don't have to support every encoding
out there.So I would suggest the following things to do:
- get rid of Jani's play branch
- move trunk to branches/FIRST_UNICODE_IDEA
- put 5.2 in security fix only mode
- pht 5.3 in bug fix only mode
- start adding new features (traits, Ilia's scalar typehint patch,
output buffering things) to the new trunk cloned from 5.3.- in the meanwhile, start working on patching in back Unicode support,
but in small steps. Exactly which things, and how we'd have to find
out. But I do think it needs to be a core language feature, and not
simply solved by extensions. We also need to make sure everybody
understands that Unicode isn't just about encodings, or charsets and
that thre are differences between that. Education is going to be
important (and adding Unicode back in small bits would certainly help
there).As I now have plenty of time to work on things, I'd be happy to act as
RM, and wouldn't mind working on roadmaps and sorting out what good bits
we have/had, and which things we don't want to port back into the new
trunk. Depending on how things go, this could become 5.4 or 6 or
something else.
FWIW, +1
Clearly, the current implementation is too difficult for people to work
with. I still think that the major principles it was built on apply, but
if people want to do a more lightweight approach that still uses those
principles, I'm not going to be in the way.
-Andrei