On 14 Oct 2014, at 20:46, Rowan Collins <[email protected]> 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/