Re: Re: PHP 5.6.0beta2 Released for Testing!

Am 2.5.2014 um 19:02 schrieb Ferenc Kovacs <tyra3l@gmail.com>: > On Fri, May 2, 2014 at 6:48 PM, Bob Weinand <bobwei9@hotmail.com> wrote: > Am 2.5.2014 um 18:28 schrieb Ferenc Kovacs <tyra3l@gmail.com>: >> On Fri, May 2, 2014 at 6:11 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote: >>> On Fri, May 2, 2014 at 5:52 PM, Hannes Magnusson <bjori@php.net> wrote: >>> >>>> On Fri, May 2, 2014 at 6:17 AM, Jan Ehrhardt <phpdev@ehrhardt.nl> wrote: >>>>> Ferenc Kovacs in php.qa (Fri, 2 May 2014 12:42:55 +0200): >>>>>>> ext\apcu\apc_bin.c(238) : error C2065: 'IS_CONSTANT_ARRAY' : >>>> undeclared >>>>>>> identifier >>>>>> >>>>>> Afair this was mentioned in UPGRADING.INTERNALS, if I remember wrong >>>> please >>>>>> open a bugreport. >>>>> >>>>> Might be that it is mentioned there (did not check yet), but to an >>>>> innocent bystander it looks like a BC break between beta1 and beta2. >>>>> >>>> >>>> >>>> >>>> l. Removal of IS_CONSTANT_ARRAY and IS_CONSTANT_INDEX hack >>>> >>>> These two #defines disappeared. Instead we have now IS_CONSTANT_AST >>>> which >>>> covers also the functionality IS_CONSTANT_ARRAY bid and furthermore the >>>> hack for marking zvals as constant index with IS_CONSTANT_INDEX is now >>>> superfluous and so removed. >>>> Please note that IS_CONSTANT_AST now has the same value than >>>> IS_CONSTANT_ARRAY had. >>>> >>>> >>>> Could someone be.. like just a tiny littlebit more professional then >>>> to shit over other people work in the upgrading notes? >>>> This is not the place for to show off how much better you are then >>>> everyone else. >>>> >>>> And why does it have to be renamed anyway? It has the same value. Does >>>> the same thing. It just got renamed to piss over people? >>>> >>>> -Hannes >>>> >>>> -- >>>> PHP Quality Assurance Mailing List >>>> <http://www.php.net/> >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>> >>>> >>> moving the discussion to internals@, CCing Bob, as he is the author of >>> the change. >>> To my understanding this change was made to fix >>> https://bugs.php.net/bug.php?id=66015 >>> I was aware that it is a BC break, but I didn't realized that it will >>> affect other extensions before the first report from the wincache dev >>> arrived. >>> Not sure if removing this #defines is really neccessary to fix the bug >>> mentioned above. >>> >>> -- >>> Ferenc Kovács >>> @Tyr43l - http://tyrael.hu >>> >> >> from a quick search search on lxr.php.net the following extensions are >> using IS_CONSTANT_ARRAY or IS_CONSTANT_INDEX >> >> - PHK >> - Parse_Tree >> - automap >> - bcompiler >> - hidef >> - AOP >> - yaf >> - APC >> - ZendOpcache >> - APCu >> - vld >> - WinCache >> >> >> and probably a couple of other exts which isn't on lxr. >> whats even more interesting is that ext/opcache still referencing both of >> those, so it isn't even cleaned up from php-src. >> what is the current workflow for opcache these days? I know that they have >> their own repo, and they are merging from there to php-src.git and that >> they are also maintain compatibility with lower versions for installing >> opcache via pecl, so maybe it is normal to have those references? >> >> personally I think that compatibility with already existing extensions is >> pretty important, because that is a major reason which holds back people >> from upgrading to new php versions early. >> so internal API breaks like that should happen early in the development >> process, have a clear communication and should be always for a good reason. >> >> -- >> Ferenc Kovács >> @Tyr43l - http://tyrael.hu > > At the time when doing this change, I had fixed all the bundled extensions. > > So, e.g. opcache shouldn't be a problem. > > my bad, on a closer look, I can see that in ext/opcache it is conditional: > #if ZEND_EXTENSION_API_NO <= PHP_5_5_API_NO > case IS_CONSTANT_ARRAY: > #endif > > Actually, I made the commit beginning of April, I think that are nearly > three months time to fix the extensions. I doubt that isn't enough… > > maybe, I just wish this could have happened a bit earlier in the process, and if we could have > communicated it better (instead of waiting for the first ext dev to complain). > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu Yeah, I agree. But it finally was relatively late when I saw that bug. And I knew PHP 5.6 bids now the possibility to fix the bug, so why not. Also I think that fix was a good idea as it's at the same time a nice refactor of some hackish things for constant keys. I hope we can now agree that it wasn't a so bad idea... Bob