# bugs.php.net & php 6 - Thread: https://externals.io/message/58078 - Original archive: https://news-web.php.net/php.internals/58078 - Started by Stas Malyshev on 2012-02-26T08:03:03+00:00 - Messages: 9 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #58078 — Stas Malyshev — 2012-02-26T08:03:03+00:00 URL: https://externals.io/message/58078#58078 Hi! Just discovered that our stock "php 4 support discontinued" message in bugs looks like: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Unless I've missed something, the "momentum for php 6" is very much nonexistent, so we probably want to fix that message :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #58079 — Rasmus Lerdorf — 2012-02-26T08:28:15+00:00 URL: https://externals.io/message/58078#58079 · In reply to: #58078 > Hi! > > Just discovered that our stock "php 4 support discontinued" message in > bugs looks like: > > We are sorry, but we can not support PHP 4 related problems anymore. > Momentum is gathering for PHP 6, and we think supporting PHP 4 will > lead to a waste of resources which we want to put into getting PHP 6 > ready. > > Unless I've missed something, the "momentum for php 6" is very much > nonexistent, so we probably want to fix that message :) Fixed --- ## #58080 — marius adrian popa — 2012-02-26T14:01:24+00:00 URL: https://externals.io/message/58078#58080 · In reply to: #58078 > Hi! > > Just discovered that our stock "php 4 support discontinued" message in bugs > looks like: > > We are sorry, but we can not support PHP 4 related problems anymore. > Momentum is gathering for PHP 6, and we think supporting PHP 4 will > lead to a waste of resources which we want to put into getting PHP 6 > ready. > > Unless I've missed something, the "momentum for php 6" is very much > nonexistent, so we probably want to fix that message :) Also i have seen a lot of skipped Unicode tests for php > 6 I wanted to ask what will happen to them ? Just one example http://gcov.php.net/viewer.php?version=PHP_5_4&func=skip&file=ext%2Fphar%2Ftests%2F017U.phpt --- ## #58134 — Richard Lynch — 2012-02-27T15:16:18+00:00 URL: https://externals.io/message/58078#58134 · In reply to: #58078 > Just discovered that our stock "php 4 support discontinued" message in > bugs looks like: > > We are sorry, but we can not support PHP 4 related problems anymore. > Momentum is gathering for PHP 6, and we think supporting PHP 4 will > lead to a waste of resources which we want to put into getting PHP 6 > ready. > > Unless I've missed something, the "momentum for php 6" is very much > nonexistent, so we probably want to fix that message :) Isn't the emotional scarring of PHP 6 == Unicode far enough in the past to start some momentum for PHP 6? I sure core Devs have thought about this, and have gone so far as to make statements for what should be in PHP 6... PS If it isn't already, I want to write an RFC to change the default error_reporting to include E_NOTICE. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE --- ## #58138 — Simon Schick — 2012-02-27T15:37:37+00:00 URL: https://externals.io/message/58078#58138 · In reply to: #58134 Hi, Richard The development of the unicode-as-default-charset should really be done within the next release coming after 5.4 I heared somewhere that it's nearly done ... I would have happily seen it in 5.4 but as this release is late right now we have to wait ;) Bye Simon p.s. * http://www.php.net/manual/en/function.error-reporting.php#refsect1-function.error-reporting-changelog * 2012/2/27 Richard Lynch > > > […] > > Isn't the emotional scarring of PHP 6 == Unicode far enough in the > past to start some momentum for PHP 6? > > I sure core Devs have thought about this, and have gone so far as to > make statements for what should be in PHP 6... > > PS > If it isn't already, I want to write an RFC to change the default > error_reporting to include E_NOTICE. > > -- > brain cancer update: > http://richardlynch.blogspot.com/search/label/brain%20tumor > Donate: > > https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE --- ## #58146 — Richard Lynch — 2012-02-27T16:10:38+00:00 URL: https://externals.io/message/58078#58146 · In reply to: #58138 > The development of the unicode-as-default-charset should really be > done > within the next release coming after 5.4 > I heared somewhere that it's nearly done ... > I would have happily seen it in 5.4 but as this release is late right > now > we have to wait ;) I was off on medical leave for awhile, but last I heard, the one (1) guy who cared enough to work hard-core on a Unicode PHP realized just how terribly difficult it was, and just how many irreconcilable issues it raised, and he stopped working on it. Nobody else has taken up the banner, and PHP 6 trunk was moth-balled and started over, or so I heard... That sums up, even over-simplifies, a whole mess of threads, discussions at conferences, and IRC discussion in a couple sentences... I apologize to all for the over-simplification, and possibly outright errors. While I understand the allure of writing code in one's native language, and the ease of having one's native language supported out of the box in the string built-in type... There are mechanisms available in PHP now, which are more cumbersome, but they work without the very complex issues alluded to in paragraph 1.. Other languages may have this feature, but they were included from the beginning. Grafting them on to PHP at this point was attempted, and, as far as I know, failed. It was an ambitious attempt, and the issues could not have easily been foreseen, so it's probably very disheartening to have failed just short of the goal line. That's the way the ball bounces sometimes. Again, please forgive me if I have completely failed to catch something here, especially as I'm just getting back into the flow of things. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE --- ## #58192 — John Crenshaw — 2012-02-27T20:58:51+00:00 URL: https://externals.io/message/58078#58192 · In reply to: #58138 Wait, is the default going to be "Unicode" (wide, always 2 bytes per char, I.E. more memory consumption) or "UTF-8" (1 byte for the first 127, more bytes for wider text, mostly unchanged memory consumption)? I thought it was originally a conversion to Unicode, but that was scrapped? Can someone clarify? John Crenshaw Priacta, Inc. -----Original Message----- From: Simon Schick [mailto:simonsimcity@googlemail.com] Sent: Monday, February 27, 2012 10:38 AM To: Richard Lynch Cc: Stas Malyshev; PHP Internals Subject: Re: [PHP-DEV] bugs.php.net & php 6 Hi, Richard The development of the unicode-as-default-charset should really be done within the next release coming after 5.4 I heared somewhere that it's nearly done ... I would have happily seen it in 5.4 but as this release is late right now we have to wait ;) Bye Simon p.s. * http://www.php.net/manual/en/function.error-reporting.php#refsect1-function.error-reporting-changelog * 2012/2/27 Richard Lynch > > > […] > > Isn't the emotional scarring of PHP 6 == Unicode far enough in the > past to start some momentum for PHP 6? > > I sure core Devs have thought about this, and have gone so far as to > make statements for what should be in PHP 6... > > PS > If it isn't already, I want to write an RFC to change the default > error_reporting to include E_NOTICE. > > -- > brain cancer update: > http://richardlynch.blogspot.com/search/label/brain%20tumor > Donate: > > https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=F > S9NLTNEEKWBE > > > > -- > To unsubscribe, > visit: http://www.php.net/unsub.php --- ## #58200 — Lester Caine — 2012-02-27T21:40:37+00:00 URL: https://externals.io/message/58078#58200 · In reply to: #58192 John Crenshaw wrote: > Wait, is the default going to be "Unicode" (wide, always 2 bytes per char, I.E. more memory consumption) or "UTF-8" (1 byte for the first 127, more bytes for wider text, mostly unchanged memory consumption)? I thought it was originally a conversion to Unicode, but that was scrapped? Can someone clarify? I seem to recall that the original plan was along the lines of windows wide string? But it was the fact that unicode is wider then 16 bit that this was simply wrong? Trying to shoehorn things into the wrong structure was just not working and making the job more difficult? Keeping things simple really requires 4 bytes per character, even if one of those is never used, but it does make sense when manipulating strings? However most of the time UTF8 works happily and only becomes a problem when a multibyte character gets cropped because the processing does not know about it? -- 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 --- ## #58202 — Ferenc Kovacs — 2012-02-27T21:53:34+00:00 URL: https://externals.io/message/58078#58202 · In reply to: #58146 > > > […] > > I was off on medical leave for awhile, but last I heard, the one (1) > guy who cared enough to work hard-core on a Unicode PHP realized just > how terribly difficult it was, and just how many irreconcilable issues > it raised, and he stopped working on it. > > Nobody else has taken up the banner, and PHP 6 trunk was moth-balled > and started over, or so I heard... > > That sums up, even over-simplifies, a whole mess of threads, > discussions at conferences, and IRC discussion in a couple > sentences... I apologize to all for the over-simplification, and > possibly outright errors. > > While I understand the allure of writing code in one's native > language, and the ease of having one's native language supported out > of the box in the string built-in type... > > There are mechanisms available in PHP now, which are more cumbersome, > but they work without the very complex issues alluded to in paragraph > 1.. > > Other languages may have this feature, but they were included from the > beginning. Grafting them on to PHP at this point was attempted, and, > as far as I know, failed. It was an ambitious attempt, and the issues > could not have easily been foreseen, so it's probably very > disheartening to have failed just short of the goal line. > > That's the way the ball bounces sometimes. > > Again, please forgive me if I have completely failed to catch > something here, especially as I'm just getting back into the flow of > things. > > some more info http://lwn.net/Articles/379909/ http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6 so yeah, the full unicode support happened to be too big to undertake (and in retrospective it seems that the UTF-8 would have been a wiser choice instead of UTF-16), and having to upgrade all of the extensions was also a grand task. so the unicode development got halted, which in turn made the whole php6 project into a death march. after some marching 5.3 got branched from 5.2, the stuff ready in php 6 got backported and released, then people realized that it is nowhere else to go, moved trunk to branches/FIRST_UNICODE_IMPLEMENTATION/, and rebranched trunk from 5.3, which in turn get turned into 5.4. ps: and it was a big messy discussion about the namespace operator. ps2: feel free to correct/extend my info. ^^ -- Ferenc Kovács @Tyr43l - http://tyrael.hu