Re: [RFC] Path to Saner Increment/Decrement operators

On 18/01/2023 18:27, Kamil Tekiela wrote:

When I read the RFC I was a little sceptical about the deprecation of string increment functionality. It's something I used in the past and I see no easy upgrade path. However, after reading this thread and thinking it over, I realize that deprecation is the right way to go. Someone said that it's useful when working with Excel. Excel uses bijective base-26 system. PHP does not. I cannot even explain what logic governs PHP string increment functionality.

The logic is actually fairly straightforward if you consider breaking the original string into blocks of alpha, numeric and non-alphameric characters; so a string like 'C-37AZ99' would be broken into five blocks of characters ('C', '-', '37', 'AZ' and '99'). Start with the rightmost block, but only if its alpha or numeric: the process will never increment any block of characters that is non-alphameric. Increment the current block. If that increment would result in an overflow (extending the size of that block) and there is another block to the "left" in the chain of blocks, then that block is reset to its "base" value (discard the overflow character), and the same process is repeated for incrementing the next block in the chain. The process terminates when there are no more blocks in the chain, or when the process encounters a non-alphameric block. The string is then "glued" back together again for the return. In this regard, when a block is alpha characters, then the increment behaviour matches "Excel's bijective base-26". -- Mark Baker