Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76843
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU5fcwWq1-xtq55xTX6URqG-Tq=z11fv2ytH7CXT4HveSw@mail.gmail.com>
References: <CAF+90c_AMJ3SLyX7eDQq-gwFLOCQUfLus+qFfJgAgTzBpZpfEg@mail.gmail.com>
	<D19D208D-06E9-4310-92DD-6F02C666138C@ajf.me>
	<CAEZPtU7yMbMSoB2imCH8NX7nCwXttpnf878vJeBK2UypJ_QxVQ@mail.gmail.com>
	<53F7F6ED.1050609@lerdorf.com>
	<CAEZPtU5+UYNJcuAnQ+ZS-U4POweEj_J=XMiP8t4zeo7jbZ_15A@mail.gmail.com>
	<53F82F16.3030601@lerdorf.com>
	<CAEZPtU7dJrZPb52u0tK9BNp6U2bP1D7wCzOw_3pDiqggd+Y2hA@mail.gmail.com>
	<53F832F0.7010601@lerdorf.com>
	<CAEZPtU4wuumiq-wo8N8FZmMwAPU+K6=Q9jQo8icLjTqfkSCZBw@mail.gmail.com>
	<53F8C3F2.1090009@lerdorf.com>
	<CAEZPtU5fcwWq1-xtq55xTX6URqG-Tq=z11fv2ytH7CXT4HveSw@mail.gmail.com>
Date: Sat, 23 Aug 2014 12:19:52 -0700
Message-ID: <CAKOpQSx71c8jBD7hCngdtNB+0+rN1UF9Ky_XF7Zsb_JKsBxfEA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8fb1f0a29267a2050150d6cf
Subject: Re: [PHP-DEV] [RFC] Better type names for int64 RFC
From: kris.craig@gmail.com (Kris Craig)

--e89a8fb1f0a29267a2050150d6cf
Content-Type: text/plain; charset=UTF-8

On Aug 23, 2014 12:10 PM, "Pierre Joye" <pierre.php@gmail.com> wrote:
>
> On Sat, Aug 23, 2014 at 6:40 PM, Rasmus Lerdorf <rasmus@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

--e89a8fb1f0a29267a2050150d6cf--