On 14 Oct 2014, at 20:46, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Just to break this down a bit: > > 1) The RFC should probably aim to make array keys consistent across > platforms. This is currently left as an unanswered question in the RFC, but > it seems natural to include it if the stated aim is to eliminate > inconsistencies. It’s something I do have an answer for, but it’ll be a separate RFC which I need to write a patch for and have pass before this one. > 2) By using an unlimited type, we open the door to constructing > "integer"-keyed arrays from 128-bit or larger sources. We also eliminate > weirdness encountered at the boundaries, such as $foo[PHP_MAX_INT] = 'hello'; > $foo[] = 'world'; - see http://3v4l.org/69mif That’s something which I would handle in the aforementioned not-yet-existant RFC. > 3) On the other hand, an implementation might be possible that allowed 64-bit > integers on 32-bit systems, but nothing more; this would potentially be both > simpler and more efficient. More efficient, as in faster? Sure, that’d be faster. Simpler? Not really. The main difficulty in this patch is updating thousands of tests and functions. The basics of it (the new type, changes to operators) are very easy. > Implementing both is probably a bad idea, as some core code would then need > to handle 3 different types of integer (native, emulated 64-bit, and GMP), > but it could be looked at as an alternative if the current RFC is rejected on > complexity or licensing grounds. As all bigint ops are abstracted, you could modify the patch to implement 64-bit integers if you wanted. Granted, they’d be unnecessarily allocated their own memory, but it’d be doable. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
