Re: [PHP-DEV] [RFC] Better type names for int64 RFC

On Sat, Aug 23, 2014 at 6:40 PM, Rasmus Lerdorf <[email protected]> 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