On Aug 23, 2014 12:10 PM, "Pierre Joye" <pierre....@gmail.com> wrote: > > On Sat, Aug 23, 2014 at 6:40 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > > On 8/22/14, 11:25 PM, Pierre Joye wrote: > >> 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. > > > > I ignored it because it is irrelevant. > > These points are not irrelevant: > > - zend_uint should go away, uint32_t should be used instead > - zend_int_t could remain. it matches the respective, architecture > specific int32_t > and int64_t being used behind it. _t standing for _typed just like > in the standard > types intXX_t > > And we can add: > > - zend_size_t can be dropped in favor of size_t > > And dangerous APIs signature changes are not irrelevant either. And > many of them are not related to performance at all but a choice made > at the implementation time. So the solid technical reason you mention > later does not apply here. > > On the same area, I would also prefer not to use STR_* defines but > directly called zend_string_*, it will drastically reduce errors > during porting or later. > > > The fact that many related things > > are changing does not justify piling on more changes. > > RIght. > > > Every change > > should have a very solid technical reason behind it. "Long is not used > > anymore" is not a solid technical reason. > > Consistent APIs, in my book, is a solid technical reason. > > > The code will compile > > perfectly fine with it being IS_LONG. Also, these are userspace-facing > > in the sense that as an extension author we are dealing with PHP's type > > system consisting of lval, dval, string, array, object and resource. How > > exactly an lval or IS_LONG is implemented at the C level on any given > > platform is an implementation detail and could change, but we are still > > providing an lval to userspace. > > Extensions write should not use the zend_value member directly but use > the provided APIs or macros, which is called Z_IVAL btw. Want to > change to Z_LVAL? WIll be more consistent. > > > As C developers, extension authors are > > more than capable of checking the actual macro definition if they want > > to know the details. > > I have not doubt about the capabilities of the extension developers, > but improving APIs quality reduces the # of errors. > > > I'd also appreciate if you would drop your toxicity level a few notches > > in your emails to the list, irc and twitter. > > I do not agree with your definition, but as long as there are double > standards and related behaviors, I do not see how things can improve. > The way this RFC has been handled is a shame. If NG would have got as > much code reviews, got blocked twice while being accepted, etc. I do > not think Dmitry or Laruence would be that happy at this point. And > seriously, this is a pretty bad behavior. It is also not the 1st time > it happens. Only difference is that I do not care much when something > happens, I know each of you long enough, but other simply left. > Anyway, it does not help anyone to argue about that over and over, I > can agree with you on that. > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
I have a quick question for the people debating this issue: Aside from the dispute over whether or not it's necessary / unimportant, are there any pressing reasons *not* to implement the changes that Pierre is advocating? I.e. would it break anything, waste a large amount of time, make the code harder to maintain, etc? Or is it just that you don't think it's worth doing? --Kris
