On Sat, Aug 23, 2014 at 8:21 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > On 8/22/14, 11:09 PM, Pierre Joye wrote: >> On Sat, Aug 23, 2014 at 8:05 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: >>> On 8/22/14, 10:46 PM, Pierre Joye wrote: >>>> In other words, it would be nice to see more developers actually >>>> porting extensions to realize the amount of changes are introduced by >>>> NG and by the int64. The sooner is in order of magnitude must larger. >>>> It is not a bad comment, only a fact. Given that, before we choose to >>>> say that it is fine for one part to change APIs/Macros signatures or >>>> names and not for another, we should really get a better view of what >>>> has actually changed. And how we can deal with our old habit to >>>> maintain one tree for many major PHP versions. For many extensions, I >>>> do not think it will be possible, or with unreadable code with 2-3x >>>> more #ifdef all over the place. >>> >>> I knew you would make this comparison. I am willing to suffer porting >>> pain if it gets me a 20% performance boost. I am completely unwilling to >>> suffer any porting pain because Pierre has decided he doesn't like the >>> names of some macros. >> >> Sorry Rasmus, this reply is irrelevant or off base. What in my reply >> makes you tell that it is about my taste? > > There is no technical reason to change IS_LONG to IS_INT along with the > others in that category. It is purely a > taste/purity/questionable-consistency thing and doesn't need to be done > to solve any real technical problem.
There is. Long is not used anymore. So we can argue about that but there is a change and it should be reflected imo. You still totally ignore any of my other points, which are even more important in regard to maintaining one code tree for 5.x and 7.x, which is very likely not possible in a sane way for many extensions. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
