# POSIX regex - Thread: https://externals.io/message/30971 - Original archive: https://news-web.php.net/php.internals/30971 - Started by Andi Gutmans on 2007-07-16T13:46:22+00:00 - Messages: 82 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/30971.md?page=2 - 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 --- ## #30971 — Andi Gutmans — 2007-07-16T13:46:22+00:00 URL: https://externals.io/message/30971#30971 Why move it to PECL? I agree that PCRE is the preferred way but not having ereg() will break a huge amount of applications for very little gain. We might possibly want to consider disabling by default but not having it in the default package doesn't make real sense. Trying to do browscap.c and pgsql.c with PCRE sounds right (if it's possible which it probably is). Andi > -----Original Message----- > From: Jani Taskinen [mailto:jani.taskinen@sci.fi] > Sent: Monday, July 16, 2007 5:48 AM > To: internals@lists.php.net > Subject: [PHP-DEV] POSIX regex > > I have moved the POSIX regex dependant functions to ext/ereg/ > extension. > > Now only places using the POSIX regex functions (ext/ereg/ > excluded) are ext/standard/browscap.c and ext/pgsql/pgsql.c. > > So what to do with these 2 places using the POSIX stuff? > Convert them to use PCRE functions or enable PCRE to be build with the > POSIX compat functions? > > ext/ereg/ is going to go to PECL anyway.. > > --Jani > > -- > To unsubscribe, > visit: http://www.php.net/unsub.php --- ## #30972 — Ilia Alshanetsky — 2007-07-16T13:48:28+00:00 URL: https://externals.io/message/30971#30972 · In reply to: #30971 > Why move it to PECL? I agree that PCRE is the preferred way but not > having ereg() will break a huge amount of applications for very little > gain. I tend to agree, unless we provide wrappers via PCRE that emulate ereg functionality I don't think we can remove posix regex until PHP 6. Ilia Alshanetsky --- ## #30973 — Andi Gutmans — 2007-07-16T13:53:00+00:00 URL: https://externals.io/message/30971#30973 · In reply to: #30972 Even in PHP 6 I am not sure it's a good idea. There are a huge amount of apps that use them and it'll be very hard for people to upgrade. Anyway, let's do some more research on that once we get closer to PHP 6 and see what the migration path looks like. We'll have to check with a few popular apps + google code search :) No need to decide on that right now without having more info. Andi > -----Original Message----- > From: Ilia Alshanetsky [mailto:ilia@prohost.org] > Sent: Monday, July 16, 2007 6:48 AM > To: Andi Gutmans > Cc: jani.taskinen@iki.fi; internals@lists.php.net > Subject: Re: [PHP-DEV] POSIX regex > > > > > > […] > very little > > […] > > I tend to agree, unless we provide wrappers via PCRE that > emulate ereg functionality I don't think we can remove posix > regex until PHP 6. > > Ilia Alshanetsky --- ## #30980 — Lukas Kahwe Smith — 2007-07-16T13:53:03+00:00 URL: https://externals.io/message/30971#30980 · In reply to: #30972 Ilia Alshanetsky wrote: > > > > > […] > > I tend to agree, unless we provide wrappers via PCRE that emulate ereg > functionality I don't think we can remove posix regex until PHP 6. Doing before PHP6 would require some very very solid wrappers. Giving the little phpt coverage (*) we currently seem to have for ereg, I do not think its really possible to be able to even determine if any attempt at a wrapper is truely solid or not. regards, Lukas (*) Actually I heard this said on IRC. I do not see an ext/ereg on gcov.php.net .. are the available tests part of regexp? --- ## #30974 — Jani Taskinen — 2007-07-16T13:59:08+00:00 URL: https://externals.io/message/30971#30974 · In reply to: #30973 Please read about the decision done regarding this and why it was done at: http://derickrethans.nl/files/meeting-notes.html#move-ereg-to-pecl This is getting quite boring. You have had over 2 years to read about this and complain..and this wasn't the first time with your usual comment "will break a huge amount of applications" about anything we're trying to improve. --Jani > Even in PHP 6 I am not sure it's a good idea. There are a huge amount of > apps that use them and it'll be very hard for people to upgrade. > Anyway, let's do some more research on that once we get closer to PHP 6 > and see what the migration path looks like. We'll have to check with a > few popular apps + google code search :) > No need to decide on that right now without having more info. > > Andi > > > […] --- ## #30975 — Pierre — 2007-07-16T13:59:28+00:00 URL: https://externals.io/message/30971#30975 · In reply to: #30973 > Even in PHP 6 I am not sure it's a good idea. As far as I know, Jani is referring to PHP6 only. And it was "decided" in the "php6 notes". I'm in favour to remove ereg in php6, and the sooner we decide the better.Users will know about this change and will finally understand the PCRE superiority and why they should use it instead, and today. As of 5.x (5.2.x or 5.3.x), I rather prefer to deprecate it in 5.3 (if any) but I don't think we should remove it in 5.x. Cheers, --Pierre --- ## #30976 — Derick Rethans — 2007-07-16T13:59:49+00:00 URL: https://externals.io/message/30971#30976 · In reply to: #30973 > Even in PHP 6 I am not sure it's a good idea. There are a huge amount of > apps that use them and it'll be very hard for people to upgrade. Their apps are breaking anyway and three regex engines doesn't make sense. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #30977 — Derick Rethans — 2007-07-16T14:13:59+00:00 URL: https://externals.io/message/30971#30977 · In reply to: #30975 > > > […] > > As far as I know, Jani is referring to PHP6 only. And it was "decided" > in the "php6 notes". Unfortunately that is not true. It's only the title of the agenda point, it's not part of the "conclusions". > I'm in favour to remove ereg in php6, and the sooner we decide the > better. Yes, I agree. > Users will know about this change and will finally understand > the PCRE superiority and why they should use it instead, and today. However, users should learn how to use the new regexp engine as that will support Unicode :) regards, Derick --- ## #30978 — Nuno Lopes — 2007-07-16T14:22:04+00:00 URL: https://externals.io/message/30971#30978 · In reply to: #30977 PCRE has a POSIX API, so it is possible to use PCRE as a drop-in replacement for the engine behind ereg(). What I don't know is how compatible it is with the current engine. But I think it worth investigating. Nuno P.S.: this POSIX PCRE layer isn't currently bundled with PHP, because it wasn't needed so far. --- ## #30979 — Lukas Kahwe Smith — 2007-07-16T14:24:49+00:00 URL: https://externals.io/message/30971#30979 · In reply to: #30973 Andi Gutmans wrote: > Even in PHP 6 I am not sure it's a good idea. There are a huge amount of > apps that use them and it'll be very hard for people to upgrade. > Anyway, let's do some more research on that once we get closer to PHP 6 > and see what the migration path looks like. We'll have to check with a > few popular apps + google code search :) > No need to decide on that right now without having more info. I disagree with this approach. The thing is that we need to get a clear message out ASAP. This all ties into topics like if we will have a unicode off/on switch or not. Delaying these decisions will hurt our userbase. We need to prepare them early. IMHO we should use PHP6 as the clean up release. Drop unicode on/off switch, accept that the bulk of all code will need to be rewritten from scratch. The benefit will be that it will truely be cleaned up, people will still be able to leverage the bulk of their PHP programming background and they can enjoy the fastest possible unicode engine we can provide them. PHP5 will be for the people that cannot make the jump. We will back port whatever we can reasonably get into PHP5. People will linger on PHP5, just as they are doing now with PHP4. So it goes. At least we will not punish the early adopters for those that are unwilling to move to the new version in the near future anyways. At any rate .. the time is now to make a decision on what its gonna be. PHP6 with BC hacks or not. regards, Lukas --- ## #30981 — Jani Taskinen — 2007-07-16T14:30:34+00:00 URL: https://externals.io/message/30971#30981 · In reply to: #30978 > PCRE has a POSIX API, so it is possible to use PCRE as a drop-in replacement > for the engine behind ereg(). What I don't know is how compatible it is with > the current engine. But I think it worth investigating. Worked fine when I tested it. But it's quite pointless, it's still not unicode friendly. It's just better to use system POSIX regex funcs if ext/ereg/ is to stay..which is stupid since all functions it provides can be easily replaced with unicode friendly preg_* funcs. Nobody should use ereg_*() for anything if they want to use unicode. If they don't need unicode, they don't need PHP 6 either. > P.S.: this POSIX PCRE layer isn't currently bundled with PHP, because it > wasn't needed so far. It is bundled, just isn't compiled, see above.. :) --Jani --- ## #30982 — Antony Dovgal — 2007-07-16T15:19:15+00:00 URL: https://externals.io/message/30971#30982 · In reply to: #30979 Thank you Lukas for expressing exactly my thoughts on this. > Andi Gutmans wrote: > > […] > > I disagree with this approach. The thing is that we need to get a clear > message out ASAP. This all ties into topics like if we will have a > unicode off/on switch or not. Delaying these decisions will hurt our > userbase. We need to prepare them early. > > IMHO we should use PHP6 as the clean up release. Drop unicode on/off > switch, accept that the bulk of all code will need to be rewritten from > scratch. The benefit will be that it will truely be cleaned up, people > will still be able to leverage the bulk of their PHP programming > background and they can enjoy the fastest possible unicode engine we can > provide them. > > PHP5 will be for the people that cannot make the jump. We will back port > whatever we can reasonably get into PHP5. People will linger on PHP5, > just as they are doing now with PHP4. So it goes. At least we will not > punish the early adopters for those that are unwilling to move to the > new version in the near future anyways. > > At any rate .. the time is now to make a decision on what its gonna be. > PHP6 with BC hacks or not. > > regards, > Lukas > -- Wbr, Antony Dovgal --- ## #30984 — Jani Taskinen — 2007-07-16T15:25:31+00:00 URL: https://externals.io/message/30971#30984 · In reply to: #30982 Thank you Lucas and Antony. Could not agree more.. > Thank you Lukas for expressing exactly my thoughts on this. > > > > […] --- ## #30986 — Pierre — 2007-07-16T15:58:47+00:00 URL: https://externals.io/message/30971#30986 · In reply to: #30984 > Thank you Lucas and Antony. Could not agree more.. But .... we all agree, don't we? :) --- ## #30985 — David Coallier — 2007-07-16T16:10:41+00:00 URL: https://externals.io/message/30971#30985 · In reply to: #30984 > Thank you Lucas and Antony. Could not agree more.. > > > > […] > > -- > > > > Another thing to mention is that without GLOBALS (PHP6), most application and php4-developers will have far more problems than without posix regex'es. D --- ## #30990 — Andi Gutmans — 2007-07-16T19:24:00+00:00 URL: https://externals.io/message/30971#30990 · In reply to: #30979 I disagree with this view of the world. It doesn't have to be a complete either/or decision and labeling everything as a "bc hacks" decision is an inacurrate and populistic way of building FUD. There are clear things we want to change (like register_globals) because we believe that ultimately they have a significant benefit to our users with controllable downside (there is an easy one line workaround which we can document for people to get their old apps to work). There are other areas where breaking BC makes sense. But saying we should just break it across the board and not even consider having a good upgrade path for our users is unreasonable. I believe we can have a very good PHP 6, which is pretty much in sync with many of your feelings, but that provides a well documented and reasonable upgrade path (unlike VB -> VB.NET). If you want to break everything and anything and don't want to be limited whatsoever by our huge user-base then maybe you should write a new language which fits exactly what your preference would be. The fact is though, that even after these discussions and the Paris discussions, the bulk of the idiosyncracies which make PHP what it is today will remain (as per agreement). So there must have been some kind of view even by the folks here that they don't want to create a new language but improve on what we have. And it's a trade-off between bang for the buck; sometimes it really brings high returns to break BC especially when it comes to security; but sometimes except for making 10 PHP devs happy who are not the bulk of our users it doesn't. So let's not oversimplify this situation. We have to continue to make trade-offs. Btw, one of PHP's strengths has been in high performance sites and with a Unicode=on only mode this would take quite a hit (but it's not the only reason why I need we need choice). In any case, I think on this question it does make sense that we start making "informed" decisions by understanding the migration path better, as opposed to just basing decisions on gut feelings. Maybe that kind of learning experience will proove me wrong (which may be so). Andi > -----Original Message----- > From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org] > Sent: Monday, July 16, 2007 7:25 AM > To: Andi Gutmans > Cc: Ilia Alshanetsky; jani.taskinen@iki.fi; internals@lists.php.net > Subject: Re: [PHP-DEV] POSIX regex > > Andi Gutmans wrote: > > […] > huge amount > > […] > closer to PHP > > […] > check with > > […] > decide on that > > […] > > I disagree with this approach. The thing is that we need to > get a clear message out ASAP. This all ties into topics like > if we will have a unicode off/on switch or not. Delaying > these decisions will hurt our userbase. We need to prepare them early. > > IMHO we should use PHP6 as the clean up release. Drop unicode > on/off switch, accept that the bulk of all code will need to > be rewritten from scratch. The benefit will be that it will > truely be cleaned up, people will still be able to leverage > the bulk of their PHP programming background and they can > enjoy the fastest possible unicode engine we can provide them. > > PHP5 will be for the people that cannot make the jump. We > will back port whatever we can reasonably get into PHP5. > People will linger on PHP5, just as they are doing now with > PHP4. So it goes. At least we will not punish the early > adopters for those that are unwilling to move to the new > version in the near future anyways. > > At any rate .. the time is now to make a decision on what its > gonna be. > PHP6 with BC hacks or not. > > regards, > Lukas --- ## #30993 — Larry Garfield — 2007-07-17T01:36:52+00:00 URL: https://externals.io/message/30971#30993 · In reply to: #30990 Non-core PHP developer speaking, so read with that in mind: One of the things that held back PHP 5 adoption for so long, IMO, is the large amount of FUD that surrounded it. Even now, 3 years after it was released, I keep seeing the argument that "I can't drop PHP 4 and use PHP 5, then I have to rewrite *everything* to use objects. I hate objects." That is, of course, completely untrue, and if you're paying even moderate attention it's not at all difficult to write code that runs just fine in both PHP 4 and PHP 5, with and without register_globals and magic_quotes. All it takes is a little forethought and not letting yourself be sloppy. Writing PHP 5/6 compatible code needs to be just as easy, if not easier, in addition to having better marketing to head off the FUD. Taking a stance of "you'll have to start from scratch if you want to be PHP 6 compatible, oh well" is an absolutely sure-fire way to guarantee that no one uses PHP 6 for anything except niche markets. If people are still relying on register_globals at this point, sure, they're screwed no matter what they do. But code written to PHP 5 `E_STRICT` standards with a recommended configuration (register_globals off, etc.) should be possible to make run successfully in PHP 6 without gutting and starting from scratch (even if you can't use the new-and-cool features). If not, "GoPHP6" will be a failure before it even gets started. :-) (And yes, I'm already pondering how to do GoPHP6 in order to make the 5/6 transition smoother.) > I disagree with this view of the world. > It doesn't have to be a complete either/or decision and labeling > everything as a "bc hacks" decision is an inacurrate and populistic way > of building FUD. > > There are clear things we want to change (like register_globals) because > we believe that ultimately they have a significant benefit to our users > with controllable downside (there is an easy one line workaround which > we can document for people to get their old apps to work). There are > other areas where breaking BC makes sense. But saying we should just > break it across the board and not even consider having a good upgrade > path for our users is unreasonable. I believe we can have a very good > PHP 6, which is pretty much in sync with many of your feelings, but that > provides a well documented and reasonable upgrade path (unlike VB -> > VB.NET). > > If you want to break everything and anything and don't want to be > limited whatsoever by our huge user-base then maybe you should write a > new language which fits exactly what your preference would be. The fact > is though, that even after these discussions and the Paris discussions, > the bulk of the idiosyncracies which make PHP what it is today will > remain (as per agreement). So there must have been some kind of view > even by the folks here that they don't want to create a new language but > improve on what we have. And it's a trade-off between bang for the buck; > sometimes it really brings high returns to break BC especially when it > comes to security; but sometimes except for making 10 PHP devs happy who > are not the bulk of our users it doesn't. > > So let's not oversimplify this situation. We have to continue to make > trade-offs. > > Btw, one of PHP's strengths has been in high performance sites and with > a Unicode=on only mode this would take quite a hit (but it's not the > only reason why I need we need choice). In any case, I think on this > question it does make sense that we start making "informed" decisions by > understanding the migration path better, as opposed to just basing > decisions on gut feelings. Maybe that kind of learning experience will > proove me wrong (which may be so). > > Andi > > > […] -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson --- ## #30994 — Lukas Kahwe Smith — 2007-07-17T06:39:50+00:00 URL: https://externals.io/message/30971#30994 · In reply to: #30990 Andi Gutmans wrote: > There are clear things we want to change (like register_globals) because > we believe that ultimately they have a significant benefit to our users > with controllable downside (there is an easy one line workaround which > we can document for people to get their old apps to work). There are > other areas where breaking BC makes sense. But saying we should just > break it across the board and not even consider having a good upgrade > path for our users is unreasonable. I believe we can have a very good > PHP 6, which is pretty much in sync with many of your feelings, but that > provides a well documented and reasonable upgrade path (unlike VB -> > VB.NET). I never said we should break BC just for the hell of it. The goal must be that PHP6 feels and behaves like PHP. Its not about high-jacking PHP to come up with the language we all wanted instead. > So let's not oversimplify this situation. We have to continue to make > trade-offs. Sure, but you are suggesting to delay decisions indefinitely. Either you are saying this because you already decided that you don't want this change, or you are accepting that our users will be unable to prepare themselves for what happens in the future. This of course will make it that much harder for them to take the plunge into PHP6. > Btw, one of PHP's strengths has been in high performance sites and with > a Unicode=on only mode this would take quite a hit (but it's not the > only reason why I need we need choice). In any case, I think on this > question it does make sense that we start making "informed" decisions by > understanding the migration path better, as opposed to just basing > decisions on gut feelings. Maybe that kind of learning experience will > proove me wrong (which may be so). I have not seen any proposed way of finding out this migration path besides lets wait. Lets wait is not the answer. What I asked for was exactly a decision on how far we are willing to go with the breakage and more importantly the fundamental decision about how we approach unicode in PHP6. The on off switch is not something that makes sense to delay until forever. Its a big decision and once its decided other things will become much easier (like PHP6 development or deciding the impact of other potential BC breaks). regards, Lukas --- ## #30995 — Lukas Kahwe Smith — 2007-07-17T06:47:42+00:00 URL: https://externals.io/message/30971#30995 · In reply to: #30993 Larry Garfield wrote: > Non-core PHP developer speaking, so read with that in mind: > > One of the things that held back PHP 5 adoption for so long, IMO, is the large > amount of FUD that surrounded it. Even now, 3 years after it was released, I > keep seeing the argument that "I can't drop PHP 4 and use PHP 5, then I have > to rewrite *everything* to use objects. I hate objects." That is, of > course, completely untrue, and if you're paying even moderate attention it's > not at all difficult to write code that runs just fine in both PHP 4 and PHP > 5, with and without register_globals and magic_quotes. All it takes is a > little forethought and not letting yourself be sloppy. I have seen little of that. But I have seen issues due to `array_merge()` changes. But more importantly our handling of `E_STRICT` has made it difficult for many. > Writing PHP 5/6 compatible code needs to be just as easy, if not easier, in > addition to having better marketing to head off the FUD. Taking a stance > of "you'll have to start from scratch if you want to be PHP 6 compatible, oh > well" is an absolutely sure-fire way to guarantee that no one uses PHP 6 for > anything except niche markets. I see it more as a question of being open about whats going on. If we would have had the upgrading guides from the beginning of 5.0.z, I think things would have been easier. The fact that our x.0.z releases are not particularly popular is another issue. I think the biggest challenge PHP5 faced however was that it was mainly about making developers life easier, since PHP4 already enables you to do pretty much any kind of web site if you are willing to put in the required time. Native unicode to me feels a bit more like adding something that was not really doable before (sure you can but that would mean writing every lib yourself, so the time required is beyond the vast majority of dev teams). Then again its not like all developers will jump on unicode the second its released (mainly because not all end users are asking for this). But the point is, getting very high adoption rates for new PHP releases will always be hard. regards, Lukas --- ## #30996 — Pierre — 2007-07-17T07:21:59+00:00 URL: https://externals.io/message/30971#30996 · In reply to: #30990 Hi Andi, > I disagree with this view of the world. Well, we seem to all agree on this view, but let forget this unsignificant fact :) > It doesn't have to be a complete either/or decision and labeling > everything as a "bc hacks" decision is an inacurrate and populistic way > of building FUD. Your persistent way to tell me (I use "me" as I'm not in the position to talk for the other developers) that my way is populist, source of a FUD, or whatever else came through your mind at a given moment . Fine, if it helps you to make your point. However, can I suggest you to seriously consider the (legitimate) voices outside your (no matter how huge it is) world, it would be much appreciated. > There are > other areas where breaking BC makes sense. But saying we should just > break it across the board and not even consider having a good upgrade > path for our users is unreasonable. For what I see in the various code I can fgrep, pcre is already used much more than pcre. To migrate from ereg to pcre is a very small task and it only brings advantages (cache, unicode support if required,...). Ironically, a little pcre based script or grep should do the job, if any regexp fan likes to play with that :) Other changes in the engine will bring much more troubles (because they are not obvious). Just like they did in the past between two minor PHP versions. > I believe we can have a very good > PHP 6, which is pretty much in sync with many of your feelings, but that > provides a well documented and reasonable upgrade path (unlike VB -> > VB.NET). It is comparing apple and orange. As far as I remember, VB.net was not really planed, they only realized how much their users liked VB and why they will not move to c* or whatever else :) > If you want to break everything and anything It is not about breaking everything just for the fun of it but about creating a sane base to create portable and maintainable application and libraries. > and don't want to be > limited whatsoever by our huge user-base then maybe you should write a > new language which fits exactly what your preference would be. The fact > is though, that even after these discussions and the Paris discussions, > the bulk of the idiosyncracies which make PHP what it is today will > remain (as per agreement). You seem to have a straight view on what should be PHP6, why don't you publish it (we have a wiki for this exact purpose) and let see that we (as PHP internals developers) think about it, the sooner the better (and once for all). Waiting indefinitely is not a solution, and taking quick decisions a week before the final release neither. Taking early decision will let us adapt them or change them if necessary. Our users will have the time to think about the consequences and tell us their needs or fears. > So let's not oversimplify this situation. We have to continue to make > trade-offs. Let's not complicate it either. > Btw, one of PHP's strengths has been in high performance sites and with > a Unicode=on only mode this would take quite a hit (but it's not the > only reason why I need we need choice). > In any case, I think on this > question it does make sense that we start making "informed" decisions by > understanding the migration path better, as opposed to just basing > decisions on gut feelings. Maybe that kind of learning experience will > proove me wrong (which may be so). With the risk to repeat myself, we already learned from PHP5. There is nothing that can prevent users to migrate quicker than they want (read: quicker that they need) except if the benefits are enormous, but that's not the case (it is but not for a large amount of users). We can keep dreaming about a short migration path for PHP6 or we can simply take the right decisions. Saying that we are not informed is a poor excuse to delay any critical decisions. We are informed, we use php daily and we have to deal "every day" with the issues we try to solve now. Cheers, --Pierre --- ## #30997 — Andi Gutmans — 2007-07-17T14:27:38+00:00 URL: https://externals.io/message/30971#30997 · In reply to: #30994 A few months ago we agreed that we will give our users the choice of both modes. The burdon of maintenance has mainly been on us btw as the majority of the differences here are in the Zend Engine and the extensions don't have as much work associated with them. Here's my proposed way of figuring how to make migration easier. Port the following applications to PHP 6 and let's see what we can learn from it: - mediaWiki - SugarCRM - Drupal - Wordpress I don't think we can have more of a reality check than actually going through this exercise and understanding the issues. As I mentioned from the small work we have done up to now it seems like there really is no migration patch except for applications to be almost completely rewritten when unicode_semantics=on. I don't think this is a feasible way to go. But if volunteers can work on this porting and it allows us to fix some things (if they are fixable) then that would change the situation. I believe that people who actually do this exercise and want to have a migration path will understand that there's no other way except to support unicode_semantics=off. Btw, most languages deliver Unicode in this way and it works pretty well. Andi > -----Original Message----- > From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org] > Sent: Monday, July 16, 2007 11:40 PM > To: Andi Gutmans > Cc: Ilia Alshanetsky; jani.taskinen@iki.fi; internals@lists.php.net > Subject: Re: [PHP-DEV] POSIX regex > > Andi Gutmans wrote: > > > […] > benefit to > > […] > old apps to > > […] > But saying > > […] > consider having > > […] > many of your > > […] > reasonable upgrade > > […] > > I never said we should break BC just for the hell of it. The > goal must be that PHP6 feels and behaves like PHP. Its not > about high-jacking PHP to come up with the language we all > wanted instead. > > > […] > continue to make > > […] > > Sure, but you are suggesting to delay decisions indefinitely. > Either you are saying this because you already decided that > you don't want this change, or you are accepting that our > users will be unable to prepare themselves for what happens > in the future. This of course will make it that much harder > for them to take the plunge into PHP6. > > > […] > (but it's not > > […] > > I have not seen any proposed way of finding out this > migration path besides lets wait. Lets wait is not the > answer. What I asked for was exactly a decision on how far we > are willing to go with the breakage and more importantly the > fundamental decision about how we approach unicode in PHP6. > The on off switch is not something that makes sense to delay > until forever. Its a big decision and once its decided other > things will become much easier (like PHP6 development or > deciding the impact of other potential BC breaks). > > regards, > Lukas --- ## #30998 — Jani Taskinen — 2007-07-17T14:36:41+00:00 URL: https://externals.io/message/30971#30998 · In reply to: #30997 Just FYI: I did not agree with that choice. And IIRC, neither did several other people here. --Jani > A few months ago we agreed that we will give our users the choice of > both modes. The burdon of maintenance has mainly been on us btw as the > majority of the differences here are in the Zend Engine and the > extensions don't have as much work associated with them. > > Here's my proposed way of figuring how to make migration easier. Port > the following applications to PHP 6 and let's see what we can learn from > it: > - mediaWiki > - SugarCRM > - Drupal > - Wordpress > > I don't think we can have more of a reality check than actually going > through this exercise and understanding the issues. As I mentioned from > the small work we have done up to now it seems like there really is no > migration patch except for applications to be almost completely > rewritten when unicode_semantics=on. I don't think this is a feasible > way to go. But if volunteers can work on this porting and it allows us > to fix some things (if they are fixable) then that would change the > situation. > > I believe that people who actually do this exercise and want to have a > migration path will understand that there's no other way except to > support unicode_semantics=off. Btw, most languages deliver Unicode in > this way and it works pretty well. > > Andi > > > […] --- ## #31000 — Lukas Kahwe Smith — 2007-07-17T14:49:59+00:00 URL: https://externals.io/message/30971#31000 · In reply to: #30997 Andi Gutmans wrote: > Here's my proposed way of figuring how to make migration easier. Port > the following applications to PHP 6 and let's see what we can learn from > it: > - mediaWiki > - SugarCRM > - Drupal > - Wordpress IIRC Wordpress is a good example of bad source code to fix. Drupal would be a good example of a PHP4 style fairly procedural app to port. mediaWiki also seems like a worthy cause since its one of those apps that would actually benefit quite a bit from unicode support, but I guess you are talking about porting with unicode==off, right? SugarCRM would be a good example of a gigantic horrible horrible source code to fix and I am not sure if I would put it on the list considering the limited open source release they do. I think it would be cool of they would do it themselves or sponsor whoever is doing it. We also have an SoC project where someone is implementing a PHP6 version of Jaws. regards, Lukas --- ## #31001 — Andi Gutmans — 2007-07-17T14:59:01+00:00 URL: https://externals.io/message/30971#31001 · In reply to: #30998 I thought you were retired at the time... > -----Original Message----- > From: Jani Taskinen [mailto:jani.taskinen@sci.fi] > Sent: Tuesday, July 17, 2007 7:37 AM > To: Andi Gutmans > Cc: internals@lists.php.net > Subject: RE: [PHP-DEV] POSIX regex > > Just FYI: I did not agree with that choice. And IIRC, neither > did several other people here. > > --Jani > > > > […] > choice of > > […] > btw as the > > […] > easier. Port > > […] > actually going > > […] > there really > > […] > completely > > […] > a feasible > > […] > it allows us > > […] > want to have a > > […] > Unicode in > > […] > internals@lists.php.net > > […] > register_globals) > > […] > wanted instead. > > […] > users will be > > […] > future. This of > > […] > performance sites and > > […] > case, I think > > […] > making "informed" > > […] > as opposed > > […] > migration path > > […] > asked for was > > […] > the breakage > > […] > we approach > > […] > delay until > > […] > things will > > […] > impact of > > […] > unsubscribe, > > […] --- ## #30999 — Andi Gutmans — 2007-07-17T15:07:19+00:00 URL: https://externals.io/message/30971#30999 · In reply to: #31000 Hmm I don't quite understand what bad code vs. good code plays here. Wordpress is one of the most popular applications out there so it's got huge value to our community. I bet there's a huge amount of PHP applications who's source code is of the same quality or worse. Anyway, the issues I have seen would also be relevant to what you call "good" code but again, when it comes to compatibility, I don't quite know why that will play a big role. I am talking about porting to both unicode_semantics=off and on. This will give us a good understanding of the difference of the modes and where we're at. I bet most people who are voicing their opinions have actually not tried to write a sizeable application with PHP 6 and also tried to run an existing one on PHP 6 (unciode_semantics=on). I can also do some performance testing in our performance lab once we have both working. I haven't yet mentioned how companies building high-performance sites would probably take a huge hit by moving to Unicode to the point where I think they will not adopt for a long time and then will be faced with the choice to migrate off of PHP or bite the bullet. With some of the companies I know that have huge server farms adding 50% capacity (or whatever the number is) could be a good enough reason to migate off as they are paying huge fees for the servers... Andi > -----Original Message----- > From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org] > Sent: Tuesday, July 17, 2007 7:50 AM > To: Andi Gutmans > Cc: Ilia Alshanetsky; jani.taskinen@iki.fi; internals@lists.php.net > Subject: Re: [PHP-DEV] POSIX regex > > Andi Gutmans wrote: > > > […] > easier. Port > > […] > > IIRC Wordpress is a good example of bad source code to fix. > Drupal would be a good example of a PHP4 style fairly > procedural app to port. > mediaWiki also seems like a worthy cause since its one of > those apps that would actually benefit quite a bit from > unicode support, but I guess you are talking about porting > with unicode==off, right? > > SugarCRM would be a good example of a gigantic horrible > horrible source code to fix and I am not sure if I would put > it on the list considering the limited open source release > they do. I think it would be cool of they would do it > themselves or sponsor whoever is doing it. > > We also have an SoC project where someone is implementing a > PHP6 version of Jaws. > > regards, > Lukas --- Next page: https://externals.io/message/30971.md?page=2