Okay I think we've both made our points. There's really no point to dwell on them much longer (and I need to hit the sack). To be honest, I'd have to re-read the whole thread to figure out how much we really agree/disagree on. It seems some of the discussion is at least semantics.
I completely understand if you don't have free time to do runtime JIT. I was only frustrated because I couldn't get a "no" out of you for quite some time. It's always better to say no then to keep someone hanging. Anyway, it's history and not a big deal anymore. We'll just have to figure something else out. Night. Andi > -----Original Message----- > From: Pierre [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 21, 2007 12:13 AM > To: Andi Gutmans > Cc: Rasmus Lerdorf; internals@lists.php.net > Subject: Re: [PHP-DEV] What is the use of "unicode.semantics" > in PHP 6? > > 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
