Hi, On 6/21/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> That's true, and this 90% doesn't care either about php6. I completely disagree. I believe there will be additional value to PHP 6 which is not only Unicode. Some is already done, some is on the way, and some we don't know yet but when the core developer team momentum turns to the latest release that's where the innovation happens.
Nothing that cannot be done in php5 too, via pecl or backported. That was one of the main arguments about "php6 without unicode makes little sense".
> > Some people here said that we weren't successful in keeping > BC between > > PHP 5 and PHP 4. Whoever said that must not have migrated > applications > > between the versions. It took very little effort to do so. > Most people > > I know did it in a matter of hours for sizeable code bases > and in fact > > most time was spent on regression testing which would need > to be done > > anyway. > > I was one who said it and I will said it again. I made many > migrations. I confirmed it was not 100% BC and it required > work. The problem (even worst after 5.x than between 4.x and > 5.x) was all changes after 5.x. The new pedantic errors added > in minor versions and other warnings, it was actually more > painfull after 5.x than between two 5.x. For a simple reason, > 4.x to 5.x issues were mostly known, it was wisely planed and decided. If tactical mistakes were made that doesn't mean we should change our philosophy.
These "tactical" mistakes cost me (and not only) more time than the php5 migration itself.
> > I also think that the fact that we *do* still support PHP 4 is a > > strength and not a weakness of the PHP project (as much as I'd like > > everyone to migrate to PHP 5). > > I agree but we don't have enough resources (as far as I > understand.) As you know, I don't consider maintaining 4.x is > a lot of work. By maintaining I mean only security fixes. It > can be done independently from any other releases and by > completely different people. > > > Sure maybe that gave less incentive to upgrade which is a bit of a > > PITA for the PHP eco-system. On the other hand look at technologies > > who didn't do that. Microsoft with VB, DNA, DCOM and some of their > > other technologies are good examples. Every version their > users would > > suffer time and time again, often having to completely > migrate their > > investment because they were not officially supported > anymore. Look at > > how Microsoft are looking to ditch XP early in the process. I don't > > think we want to follow that path. The fact that we do our > best not to > > break BC and are very careful when doing it is a HUGE plus > for us. Not > > to mention still doing security and critical fixes for PHP 4. > > It was not well done. A 3 commits release required months to > be released, that's simply unreliable. If we like to keep > every releases active for years, we have to change a couple > of things in our model (see the archives to get some tips). I don't want to get into personal tactical arguments here (and I know exactly what you are referring to which I think is not relevant for this conversation). Again, I don't think they warrant a strategic change in our philosophy.
It is not tactical, it is a critical and strategic part of our model. It is about time to understand that. I did not refer to individuals but to the project at large. And I do think that we need a change, not philosophical but in the ways we work and communicate. Read: lay down the pyramid inside the core developers, that will surely give us more resources to manage releases in a same way.
> > Btw, on the "if (UG(unicode)" issue. That's really a bunch of BS. > > With all respects, how many extensions do you maintain? How > many commits do you actually do? Please don't tell me that > what I said about the extra work required about the two modes > is BS. Well, you don't say directly but you include every > argument in the BS :) Actually I am probably deeper into this than most people as not only do I review a large amount of these patches but I also have people here who have to go the extra mile to do this extra work. It means lower productivity out of some people here but I think it's worth it. The sensitivity on my side is very high to maintenance costs as I pay it every day (this also included runtime JIT).
Yes, the questions were actually rhetoric. Even if you don't commit yourself, we know that you are behind many commits. The points remain the same, it is a lot more work.
> > I have always been against premature optimizations and I can pretty > > much promise that the "if (UG(unicode))" is not going to be > an issue. > > It's a bit more code yes. But I think it's worth it. > > Most of us are against it for two reasons: > - php6 without unicode makes no sense. The impact will be > much more damageable than > magic gpc on/off or any other flags we had until now > - the extra work required > > I think we all agree than the slowness is not yet an > argument. Even if it was, it is a non issue (as you well explained). I completely disagree. I think PHP 6 without unicode_semantics=on makes HUGE sense. So much sense that I think the majority of PHP 6 users will be unicode_semantics=off but will still have jumped on the PHP 6 boat.
If it is really the case (I seriously doubt), then we should move _all_ unicode specific code into its own extension, give it to whoever is interested/needs it and that's all (like what lotek works on for example). It will not provide all the fancy things like writing php scripts in random languages, but it should be possible to provide nearly everything else.
> > We had a lot of discussions on this issue within the core > development > > team and I think there was a strong enough case to keep > things this way. > > If we are proven wrong down the road then there's always > PHP 6.5 or 7 > > where we can nuke the 8bit mode. But my guess is that at > least 80%+ of > > PHP 6 users will not run in Unicode mode. For many there's just not > > sufficient reason to do so. > > That's the worst thing to do. Breaking things between 6.0 and > 6.x is a no-no here. In the same manner, if we keep the flag, > we will have to keep it. Or why php7 will be a better moment > than php6? That simply makes no sense. It makes great sense. If you are right and 99% of PHP 6 users use Unicode then we'd probably be willing to make life hard for the remaining 1% of the users. It will have meant that there's both huge interest in Unicode *and* that we did such a great job that there were no BC issues (unlikely). In case you didn't understand what I wrote, the point is obviously that I believe this will NOT happen.
You believed it too in php5.
P.S. - Whatever happened to runtime JIT?
The ping pong ball went back in Andrei&co hands, as far as I can tell (see the archive a couple of weeks ago). So for my own sanity (and coolness until now), communicate and personal attacks (your next post) is not going to help! --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
