Negative string offsets

On Thu, Apr 17, 2014 at 2:11 PM, Christian Stoller stoller@leonex.dewrote:

What are peoples thoughts on allowing negative string offsets, that
return
characters from the end of a string.

Example:

$string = 'foobar';
print $string[-1]; // prints 'r';
print $string[-2]; // prints 'a';

Generally I like this, but I think it's confusing and inconsistent in
comparison to array-indiexes, as you can have an array like array(-1 => 'foo')

And in my opinion one should not have differences in $string[x] and
$array[x] access.

That's an interesting notion, but I think in previous discussions the
consensus was that array-index access and string offset were never going to
be the same since non numeric array keys or multi-associative, etc don't
translate to string offsets anyway.

Can't remember how long/in regards to what this was, though!

Hi,

On Thu, Apr 17, 2014 at 6:07 PM, Johannes Schlüter
johannes@schlueters.de wrote:

For example, every time you need to check for a filename extension,
last segment of a path, etc. When I need that, I always endup with
substr(), strrchr() or explode(), end() ... both are suboptimal.

I don't see where this helps in that case.

    $sep = strrpos($filename, ".");
    if ($sep !== false) {
        $ext = substr($filename, $sep + 1);
    }

is clear and concise, two fcalls, can be understood even after years and
the new programmer easily.

This is the most concise form I came up using this new offset:

    $ext = '';
    $pos = -1;
    do {
        $ext = $filename[$pos].$ext;
    } while ($filename[--$pos] != '.');

While this form is bugged as it assumes that there is a . without
checking. For checking I'd have to use strlen(), but if i call strlen()
I can also initialize $pos accordingly and iterate from strlen() to 0.
Also this form does more comparisons and way more allocations and is (in
my opinion) way harder to understand.

Maye I didn't see a simple form ...

johannes

For most filename extensions:

if ($filename[-4] === '.')
{
    $ext = substr($filename, -3);
}

Or, checking if a path has a slash at the end:

if ($path[-1] === '/') { ... }

I'm talking strictly about validation here (and yes, the filename
example won't work with i.e. .jpeg, but would satisfy a large amount
of use cases), comparing stuff on the fly.

Cheers,
Andrey.

I'm +/-0 on this. But mind: Current form makes it simpler to find bugs
when miscalculating the offset. Allowing negative offsets gives harder
to debug results. Additionally I wonder how often this is actually
needed, thus justifying to change the language rules.

I really don't know how often it would be needed, the patch comes from my
own selfish reasons. I needed it today so I knocked something up. (I was
dealing with string padding). We already have functions that accept
negative offsets to produce similar behaviour, so I thought it might fit
in. If the consensus is that it does not fit, then I'm happy to leave it at
that.

Generally I like this, but I think it's confusing and inconsistent in
comparison to array-indiexes, as you can have an array like array(-1 => 'foo')

I'm with Daniel on this one, I'd trust developers to know when they are
dealing with a string or an array.

I warned this would lead to the Python syntax...

Of course, this is the php-bikeshedding list. I have to wonder though, do I
take this as "full python compat or gtfo", or just ignore it, and hope for
some actual responses on the issue under discussion.

Although the syntax and ability is for the most part usefull, people forget
the unicode problem.
What should we let it traverse? Bytes or characters? Right now it is bytes,
but it is rarelly used and people use functions and mb_* for unicode.

This can be discussed only when we have full unicode, before that it is
useless and just generates a ton of problems and takes time implementing
from other more usefull stuff.

A giant -1 from me.

What unicode problem? The proposed behaviour is the same as is currently
implemented.

Not sure why you think string offsets are rarely used, my experience is
exactly the opposite.

I'm just going to go ahead and assume you think this thread is about
python-style slice syntax.

It is not.