Hi Andi, On 7/16/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
