Re: [VOTE] [RFC] 64 bit platform improvements for string length and integer

From: Date: Mon, 19 May 2014 12:21:11 +0000
Subject: Re: [VOTE] [RFC] 64 bit platform improvements for string length and integer
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-74358@lists.php.net to get a copy of this message
On Sat, 2014-05-17 at 14:15 +0300, Zeev Suraski wrote: > For the benefit of everyone, this is all from January. Dmitry's, > Stas's and Nikita's positions in the actual patch in question can be > found on this thread. It should be known that I usually won't support Pierre, but the way this discussion goes is really bad. There was a long debated and quite openly developed patch. When it was initially proposed form my perspective the result was "this might be good, timing is bad, we can't put it in 5.6" Then some who participated in that debate had an idea and implemented, ignored the existence of the public known work while working on something contrary and none found the time to (publicly) discuss this. This is really bad. On the other side the attempt to push the size_t/int64 thing now looks like an attempt to push it through now as a reaction, more for "political" than technical reasons. This is bad, too. (While I understand how ridiculous it is to first argue "now it is too late for 5.6" and then "oh, now it is too early for PHP.Next" as I'm essentially doing) What we as a community (both (engine) maintainers as well as user communities) have to decide is how much performance loss we are willing to pay for "clean" and "quality" code and how to find the balance. Maybe an approach might be not using a single zend_string type everywhere but have different types lie zend_small_string for usage in opcode members (class names, function names, .. would almost certainly fit into a (unsigned) char and are for the most part engine internal so places for extra range checks should be minimal. So please, let's try to avoid confrontation and let's try to define our common goals and then finding a compromise for the technical questions. johannes

Attachment: [application/pgp-signature] This is a digitally signed message part signature.asc
« previous php.internals (#74358) next »