FAQ
I am wondering what are people's opinions on adding support for negative
string offsets that could be used to access data from the end of a string.

Ex. $a = "123"; echo $a[-1]; // would print 3

I don't think we should do this for arrays, since -1 and similar are
valid array keys, which means adding this support for arrays would break BC.

Ilia

Search Discussions

  • Greg Beaver at Oct 29, 2004 at 7:34 pm

    Ilia Alshanetsky wrote:
    I am wondering what are people's opinions on adding support for negative
    string offsets that could be used to access data from the end of a string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would break
    BC.
    I need this, +1

    Greg
  • Derick Rethans at Oct 29, 2004 at 11:05 pm

    On Fri, 29 Oct 2004, Greg Beaver wrote:

    Ilia Alshanetsky wrote:
    I am wondering what are people's opinions on adding support for negative
    string offsets that could be used to access data from the end of a string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would break
    BC.
    I need this, +1
    How can you *need* this, you can use substr() just fine.

    Derick
  • Andi Gutmans at Oct 29, 2004 at 11:21 pm

    At 01:05 AM 10/30/2004 +0200, Derick Rethans wrote:
    On Fri, 29 Oct 2004, Greg Beaver wrote:

    Ilia Alshanetsky wrote:
    I am wondering what are people's opinions on adding support for negative
    string offsets that could be used to access data from the end of a
    string.
    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would break
    BC.
    I need this, +1
    How can you *need* this, you can use substr() just fine.
    Yeah, I also thought the word "need" is a bit strong :) It's more like
    "syntactic sugar which is nice-to-have"

    Andi
  • Derick Rethans at Oct 29, 2004 at 11:29 pm

    On Fri, 29 Oct 2004, Andi Gutmans wrote:

    Yeah, I also thought the word "need" is a bit strong :) It's more like
    "syntactic sugar which is nice-to-have"
    As I just told Ilia on IRC, I think we should not add this (now) for a
    couple of reasons:

    - Adding new language constructs in mini releases is IMO not the way to
    go as it will make it possible impossible to run script that use this
    new construct not even parse on PHP 5.0.x servers. Adding normal new
    functions does not have this problem of course, as those scripts are
    still parsable.
    - Substring works just fine, adding this for performance reasons is IMO
    invalid.
    - People might want to take this even further and request {1,3}, {-3,2}
    and the like. (This was expressed in the past when talking about this
    stuff)

    regards,
    Derick
  • Sterling Hughes at Oct 29, 2004 at 11:36 pm
    I think we should not follow this discussion on internals@ and instead
    we should have a subcommittee to study whether or not the word need
    was appropriate in the context of the substring operator, or whether
    in fact, "would be nice to have, but might be able to continue living"
    would've been a more appropriate form of expression.

    -Sterling


    On Sat, 30 Oct 2004 01:29:46 +0200 (CEST), Derick Rethans
    wrote:
    On Fri, 29 Oct 2004, Andi Gutmans wrote:

    Yeah, I also thought the word "need" is a bit strong :) It's more like
    "syntactic sugar which is nice-to-have"
    As I just told Ilia on IRC, I think we should not add this (now) for a
    couple of reasons:

    - Adding new language constructs in mini releases is IMO not the way to
    go as it will make it possible impossible to run script that use this
    new construct not even parse on PHP 5.0.x servers. Adding normal new
    functions does not have this problem of course, as those scripts are
    still parsable.
    - Substring works just fine, adding this for performance reasons is IMO
    invalid.
    - People might want to take this even further and request {1,3}, {-3,2}
    and the like. (This was expressed in the past when talking about this
    stuff)

    regards,


    Derick

    --
    Derick Rethans
    http://derickrethans.nl | http://ez.no | http://xdebug.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Robert Cummings at Oct 30, 2004 at 12:07 am

    On Fri, 2004-10-29 at 19:29, Derick Rethans wrote:
    On Fri, 29 Oct 2004, Andi Gutmans wrote:

    Yeah, I also thought the word "need" is a bit strong :) It's more like
    "syntactic sugar which is nice-to-have"
    As I just told Ilia on IRC, I think we should not add this (now) for a
    couple of reasons:

    - Adding new language constructs in mini releases is IMO not the way to
    go as it will make it possible impossible to run script that use this
    new construct not even parse on PHP 5.0.x servers. Adding normal new
    functions does not have this problem of course, as those scripts are
    still parsable.
    - Substring works just fine, adding this for performance reasons is IMO
    invalid.
    - People might want to take this even further and request {1,3}, {-3,2}
    and the like. (This was expressed in the past when talking about this
    stuff)
    Reading this after writing my comment about speed. If I could get a
    substring at 50% of the current substring function's time cost because
    the above operator existed then I'd be all over it. While I agree syntax
    is an issue because the PHP developers want to keep the language very
    clear so that clueless newbies don't get confused, considering the {}
    operator has only one purpose right now for strings, I don't think the
    above concept would be at all hurtful to the PHP philosophy.

    Cheers,
    Rob.
    --
    .------------------------------------------------------------.
    InterJinn Application Framework - http://www.interjinn.com |
    :------------------------------------------------------------:
    An application and templating framework for PHP. Boasting |
    a powerful, scalable system for accessing system services |
    such as forms, properties, sessions, and caches. InterJinn |
    also provides an extremely flexible architecture for |
    creating re-usable components quickly and easily. |
    `------------------------------------------------------------'
  • Robert Cummings at Oct 30, 2004 at 12:09 am

    On Fri, 2004-10-29 at 19:29, Derick Rethans wrote:
    On Fri, 29 Oct 2004, Andi Gutmans wrote:

    Yeah, I also thought the word "need" is a bit strong :) It's more like
    "syntactic sugar which is nice-to-have"
    As I just told Ilia on IRC, I think we should not add this (now) for a
    couple of reasons:

    - Adding new language constructs in mini releases is IMO not the way to
    go as it will make it possible impossible to run script that use this
    new construct not even parse on PHP 5.0.x servers. Adding normal new
    functions does not have this problem of course, as those scripts are
    still parsable.
    BTW, I agree with the above argument... not that my agreeing or
    disagreeing counts for much :)

    Cheers,
    Rob.
    --
    .------------------------------------------------------------.
    InterJinn Application Framework - http://www.interjinn.com |
    :------------------------------------------------------------:
    An application and templating framework for PHP. Boasting |
    a powerful, scalable system for accessing system services |
    such as forms, properties, sessions, and caches. InterJinn |
    also provides an extremely flexible architecture for |
    creating re-usable components quickly and easily. |
    `------------------------------------------------------------'
  • Sara Golemon at Oct 30, 2004 at 12:51 am

    - Adding new language constructs in mini releases is IMO not the way to
    go as it will make it possible impossible to run script that use this
    new construct not even parse on PHP 5.0.x servers. Adding normal new
    functions does not have this problem of course, as those scripts are
    still parsable.
    I agree that it introduces the problem of individuals writing scripts which
    rely on this feature then publishing them and other users getting
    hurt/angry/confused when it doesn't work. However, I don't think that a
    major version (4->5) is any better than a minor version (5.0->5.1) as more
    than a few people are having issues with PHP5 specific OOP code breaking in
    4.3 installations (i.e. PPP access modifiers).

    Though to be fair... This doesn't prevent the scripts from parsing, it just
    makes then behave incorectly (probably worse overall, but there is a
    distinction).
    - Substring works just fine, adding this for performance reasons is IMO
    invalid.
    Absolutely, were a feature like this introduced, I (personally) would
    continue to use substr($str, -1) for at least a couple minor versions to
    come in the name of BC. However, when those extra couple minor versions
    have passed, I'd feel much better about using a feature that's "been around
    since the 5.1 days"... silly though it may be.
    - People might want to take this even further and request {1,3}, {-3,2}
    and the like. (This was expressed in the past when talking about this
    stuff)
    They might... and the response to that is that it's a more siginificant
    modification/glut of the exisiting code than merely allowing negative
    offsets. The fact is allowing negative string offsets via the {} operator
    involves changing one line, and it's no major waste of CPU cycles. Full
    substr()esque behavior would be more bloat-intensive of course and I'd be
    inclined to side against that.

    -Sara

    Index: Zend/zend_execute.c
    ===================================================================
    RCS file: /repository/ZendEngine2/zend_execute.c,v
    retrieving revision 1.684
    diff -u -r1.684 zend_execute.c
    --- Zend/zend_execute.c 22 Oct 2004 21:42:14 -0000 1.684
    +++ Zend/zend_execute.c 30 Oct 2004 00:46:13 -0000
    @@ -1210,7 +1210,7 @@
    container = *container_ptr;
    result->str_offset.str = container;
    PZVAL_LOCK(container);
    - result->str_offset.offset =
    dim->value.lval;
    + result->str_offset.offset =
    dim->value.lval >= 0 ? dim->value.lval : (dim->value.lval +
    container->value.str.len);
    result->var.ptr_ptr = NULL;
    if (type == BP_VAR_R || type ==
    BP_VAR_IS) {
    AI_USE_PTR(result->var);
  • Andi Gutmans at Oct 30, 2004 at 1:02 am
    Nah that patch won't do because it'll effect [] also.
    It's more complicated than that. I've tried separating them in the past and
    it was annoying (and didn't have time to finish it off).

    Andi
    At 05:51 PM 10/29/2004 -0700, Sara Golemon wrote:
    - Adding new language constructs in mini releases is IMO not the way to
    go as it will make it possible impossible to run script that use this
    new construct not even parse on PHP 5.0.x servers. Adding normal new
    functions does not have this problem of course, as those scripts are
    still parsable.
    I agree that it introduces the problem of individuals writing scripts which
    rely on this feature then publishing them and other users getting
    hurt/angry/confused when it doesn't work. However, I don't think that a
    major version (4->5) is any better than a minor version (5.0->5.1) as more
    than a few people are having issues with PHP5 specific OOP code breaking in
    4.3 installations (i.e. PPP access modifiers).

    Though to be fair... This doesn't prevent the scripts from parsing, it just
    makes then behave incorectly (probably worse overall, but there is a
    distinction).
    - Substring works just fine, adding this for performance reasons is IMO
    invalid.
    Absolutely, were a feature like this introduced, I (personally) would
    continue to use substr($str, -1) for at least a couple minor versions to
    come in the name of BC. However, when those extra couple minor versions
    have passed, I'd feel much better about using a feature that's "been around
    since the 5.1 days"... silly though it may be.
    - People might want to take this even further and request {1,3}, {-3,2}
    and the like. (This was expressed in the past when talking about this
    stuff)
    They might... and the response to that is that it's a more siginificant
    modification/glut of the exisiting code than merely allowing negative
    offsets. The fact is allowing negative string offsets via the {} operator
    involves changing one line, and it's no major waste of CPU cycles. Full
    substr()esque behavior would be more bloat-intensive of course and I'd be
    inclined to side against that.

    -Sara

    Index: Zend/zend_execute.c
    ===================================================================
    RCS file: /repository/ZendEngine2/zend_execute.c,v
    retrieving revision 1.684
    diff -u -r1.684 zend_execute.c
    --- Zend/zend_execute.c 22 Oct 2004 21:42:14 -0000 1.684
    +++ Zend/zend_execute.c 30 Oct 2004 00:46:13 -0000
    @@ -1210,7 +1210,7 @@
    container = *container_ptr;
    result->str_offset.str = container;
    PZVAL_LOCK(container);
    - result->str_offset.offset =
    dim->value.lval;
    + result->str_offset.offset =
    dim->value.lval >= 0 ? dim->value.lval : (dim->value.lval +
    container->value.str.len);
    result->var.ptr_ptr = NULL;
    if (type == BP_VAR_R || type ==
    BP_VAR_IS) {
    AI_USE_PTR(result->var);

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Sara Golemon at Oct 30, 2004 at 4:19 am
    "Andi Gutmans" <andi@zend.com> wrote in message
    news:5.1.0.14.2.20041029180202.043971b0@localhost...
    Nah that patch won't do because it'll effect [] also.
    It's more complicated than that. I've tried separating them in the past
    and it was annoying (and didn't have time to finish it off).

    Andi
    True... I should have mentioned that I don't personally see a problem with
    it working in both modes. :)

    -Sara
  • Ilia Alshanetsky at Oct 30, 2004 at 6:02 am

    Derick Rethans wrote:
    - Adding new language constructs in mini releases is IMO not the way to
    go as it will make it possible impossible to run script that use this
    new construct not even parse on PHP 5.0.x servers. Adding normal new
    functions does not have this problem of course, as those scripts are
    still parsable.
    IMO a mini release is a Z.X.Y not a Z.X release. The 5.1 release in
    particular introduces far more reaching changes already then this minor
    feature I am suggesting.
    - Substring works just fine, adding this for performance reasons is IMO
    invalid.
    I presume you have some benchmarks to prove this, I'd very much like to
    see those.
    - People might want to take this even further and request {1,3}, {-3,2}
    and the like. (This was expressed in the past when talking about this
    stuff)
    This functionality that you mention is not even on the table, we are
    talking about a very specific feature. If someone wanted {1,3} and
    similar support it would be a completely separate matter.

    Ilia
  • Zeev Suraski at Oct 31, 2004 at 9:52 am

    At 08:02 30/10/2004, Ilia Alshanetsky wrote:
    Derick Rethans wrote:
    - Adding new language constructs in mini releases is IMO not the way to
    go as it will make it possible impossible to run script that use this
    new construct not even parse on PHP 5.0.x servers. Adding normal new
    functions does not have this problem of course, as those scripts are
    still parsable.
    IMO a mini release is a Z.X.Y not a Z.X release. The 5.1 release in
    particular introduces far more reaching changes already then this minor
    feature I am suggesting.
    - Substring works just fine, adding this for performance reasons is IMO
    invalid.
    I presume you have some benchmarks to prove this, I'd very much like to
    see those.
    His point (I believe) is that introducing this patch for performance
    reasons, regardless of whether it makes a big difference or not, is
    invalid. He's not saying that it won't improve performance - he's saying
    that adding this with performance being the key reason is wrong. As in the
    past, I very much agree with this principle. Performance should play
    little if any role in our decision to add language-level operators.

    I have no strong opinion either way about this syntax addition in
    particular, but I lean in favour of adding it. I think it's a
    nice-to-have, that might actually be useful by clarifying code, rather than
    (by just) speeding it up. One advantage that this syntax has over other
    suggestions we've seen in the past is that it is quite easy to figure out
    what it does (either by guessing or checking), and once established, can
    actually result in more readable code.

    Zeev
  • Moshe doron at Oct 31, 2004 at 9:37 am

    Derick Rethans wrote:

    On Fri, 29 Oct 2004, Andi Gutmans wrote:

    Yeah, I also thought the word "need" is a bit strong :) It's more like
    "syntactic sugar which is nice-to-have"

    As I just told Ilia on IRC, I think we should not add this (now) for a
    couple of reasons:

    - Adding new language constructs in mini releases is IMO not the way to
    go as it will make it possible impossible to run script that use this
    new construct not even parse on PHP 5.0.x servers. Adding normal new
    functions does not have this problem of course, as those scripts are
    still parsable.
    - Substring works just fine, adding this for performance reasons is IMO
    invalid.
    - People might want to take this even further and request {1,3}, {-3,2}
    and the like. (This was expressed in the past when talking about this
    stuff)
    where the problem about 'taking it ever further'?
    I'm +1 for {-1} and more +1 for {-4,2} python likeness.

    Moshe.
  • Rasmus Lerdorf at Oct 31, 2004 at 10:27 pm

    On Sun, 31 Oct 2004, moshe doron wrote:
    where the problem about 'taking it ever further'?
    I'm +1 for {-1} and more +1 for {-4,2} python likeness.
    That starts getting confusing. I assume that translates to the 3rd and
    4th chars from the end of the string. And, to verify that I went and
    looked it up and it turns out that's not the case in Python. They use
    [start_index:end_index] so [-4:2] would be the 4th char from the end until
    the 2nd char in the string, so for a 6 char string or longer that would
    return nothing, but worse, my initial guess at what it did was wrong. I
    don't like features where my first guess at what something does is wrong.

    -Rasmus
  • Marcus Boerger at Oct 31, 2004 at 10:35 pm
    Hello Rasmus,

    Sunday, October 31, 2004, 11:27:40 PM, you wrote:
    On Sun, 31 Oct 2004, moshe doron wrote:
    where the problem about 'taking it ever further'?
    I'm +1 for {-1} and more +1 for {-4,2} python likeness.
    That starts getting confusing. I assume that translates to the 3rd and
    4th chars from the end of the string. And, to verify that I went and
    looked it up and it turns out that's not the case in Python. They use
    [start_index:end_index] so [-4:2] would be the 4th char from the end until
    the 2nd char in the string, so for a 6 char string or longer that would
    return nothing, but worse, my initial guess at what it did was wrong. I
    don't like features where my first guess at what something does is wrong.
    Same from here. If we do it it should behave like a short form of substr.

    Best regards,
    Marcus mailto:helly@php.net
  • Greg Beaver at Oct 31, 2004 at 10:45 pm

    Marcus Boerger wrote:
    Hello Rasmus,

    Sunday, October 31, 2004, 11:27:40 PM, you wrote:

    On Sun, 31 Oct 2004, moshe doron wrote:

    where the problem about 'taking it ever further'?
    I'm +1 for {-1} and more +1 for {-4,2} python likeness.
    That starts getting confusing. I assume that translates to the 3rd and
    4th chars from the end of the string. And, to verify that I went and
    looked it up and it turns out that's not the case in Python. They use
    [start_index:end_index] so [-4:2] would be the 4th char from the end until
    the 2nd char in the string, so for a 6 char string or longer that would
    return nothing, but worse, my initial guess at what it did was wrong. I
    don't like features where my first guess at what something does is wrong.

    Same from here. If we do it it should behave like a short form of substr.
    {} returns a single character a certain offset from 0, I don't see any
    reason to implement any of substr's advanced features. $a{3} returns
    the 4th character. $a{-3} would return the 4th character from the end.
    Simple, end of story. It would reduce the errors I inevitably get
    whenever using a complex feature like substr(). The three choices:

    1) substr($a, strlen($a) - 1);
    2) $a{strlen($a) - 1}
    3) $a{-1}

    It's pretty obvious that the 3rd choice lowers the potential for all
    kinds of bugs (mistypign, wrong parameter name, incorrect parameter
    placement), and is much more readable. For those who already know how
    {} works in PHP, it's also obvious what it does at the first look
    without any speculation.

    Greg
  • Wez Furlong at Nov 1, 2004 at 1:29 am
    Doesn't substr($a, -1) work ?

    --Wez.
    On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver wrote:
    It would reduce the errors I inevitably get
    whenever using a complex feature like substr(). The three choices:

    1) substr($a, strlen($a) - 1);
    2) $a{strlen($a) - 1}
    3) $a{-1}

    It's pretty obvious that the 3rd choice lowers the potential for all
    kinds of bugs (mistypign, wrong parameter name, incorrect parameter
    placement), and is much more readable. For those who already know how
    {} works in PHP, it's also obvious what it does at the first look
    without any speculation.
  • Greg Beaver at Nov 1, 2004 at 1:56 am

    Wez Furlong wrote:
    Doesn't substr($a, -1) work ?
    I knew that looked funny, but couldn't figure out why for some reason,
    thanks for the good catch.

    Greg
  • Marcus Boerger at Nov 1, 2004 at 2:04 am
    Hello Wez,

    well it would. However 5.1 aims to be a major speed improvement and that's
    what the idea is about.

    best regards
    marcus

    Monday, November 1, 2004, 2:29:46 AM, you wrote:
    Doesn't substr($a, -1) work ?
    --Wez.
    On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver wrote:
    It would reduce the errors I inevitably get
    whenever using a complex feature like substr(). The three choices:

    1) substr($a, strlen($a) - 1);
    2) $a{strlen($a) - 1}
    3) $a{-1}

    It's pretty obvious that the 3rd choice lowers the potential for all
    kinds of bugs (mistypign, wrong parameter name, incorrect parameter
    placement), and is much more readable. For those who already know how
    {} works in PHP, it's also obvious what it does at the first look
    without any speculation.



    --
    Best regards,
    Marcus mailto:helly@php.net
  • Sterling Hughes at Nov 1, 2004 at 6:03 am
    i hope not. this should be about what's cool for developers, the
    speed increase is not a compelling reason.. the debate is "does this
    make code easier to read/write/maintain?" I think it doesn't, and
    therefore am against it.

    -sterling

    On Mon, 1 Nov 2004 03:04:45 +0100, Marcus Boerger wrote:
    Hello Wez,

    well it would. However 5.1 aims to be a major speed improvement and that's
    what the idea is about.

    best regards
    marcus



    Monday, November 1, 2004, 2:29:46 AM, you wrote:
    Doesn't substr($a, -1) work ?
    --Wez.
    On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver wrote:
    It would reduce the errors I inevitably get
    whenever using a complex feature like substr(). The three choices:

    1) substr($a, strlen($a) - 1);
    2) $a{strlen($a) - 1}
    3) $a{-1}

    It's pretty obvious that the 3rd choice lowers the potential for all
    kinds of bugs (mistypign, wrong parameter name, incorrect parameter
    placement), and is much more readable. For those who already know how
    {} works in PHP, it's also obvious what it does at the first look
    without any speculation.
    --
    Best regards,
    Marcus mailto:helly@php.net

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derick Rethans at Nov 1, 2004 at 7:30 am

    On Sun, 31 Oct 2004, Sterling Hughes wrote:

    i hope not. this should be about what's cool for developers, the
    speed increase is not a compelling reason.. the debate is "does this
    make code easier to read/write/maintain?" I think it doesn't, and
    therefore am against it.
    And I agree with this, speed should not be the reason to add this as
    Zeev correctly interpolated from my earlier mails.

    Derick
  • Ilia Alshanetsky at Nov 1, 2004 at 2:45 pm
    IMO {-1} syntax is not only faster but simpler to use then the
    equivalent substr() (for read) or $a[strlen($a) - 1] (for write). While
    my reasons are primarily performance based, I think that most people
    would find the {-1} simpler to use as well.

    Ilia

    Sterling Hughes wrote:
    i hope not. this should be about what's cool for developers, the
    speed increase is not a compelling reason.. the debate is "does this
    make code easier to read/write/maintain?" I think it doesn't, and
    therefore am against it.

    -sterling

    On Mon, 1 Nov 2004 03:04:45 +0100, Marcus Boerger wrote:

    Hello Wez,

    well it would. However 5.1 aims to be a major speed improvement and that's
    what the idea is about.

    best regards
    marcus



    Monday, November 1, 2004, 2:29:46 AM, you wrote:

    Doesn't substr($a, -1) work ?
    --Wez.
    On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver wrote:

    It would reduce the errors I inevitably get
    whenever using a complex feature like substr(). The three choices:

    1) substr($a, strlen($a) - 1);
    2) $a{strlen($a) - 1}
    3) $a{-1}

    It's pretty obvious that the 3rd choice lowers the potential for all
    kinds of bugs (mistypign, wrong parameter name, incorrect parameter
    placement), and is much more readable. For those who already know how
    {} works in PHP, it's also obvious what it does at the first look
    without any speculation.
    --
    Best regards,
    Marcus mailto:helly@php.net

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • John Coggeshall at Nov 1, 2004 at 2:58 pm
    I honestly don't really care about the performance side of things, I'd
    be very surprised if this sort of calculation is going to be in the top
    5 bottlenecks of an application. However, from a development point of
    view I do find $a{-1} a much shorter and cleaner way of calculating an
    end-of-string offset and would like to see it implemented.
    On Mon, 2004-11-01 at 09:44, Ilia Alshanetsky wrote:
    IMO {-1} syntax is not only faster but simpler to use then the
    equivalent substr() (for read) or $a[strlen($a) - 1] (for write). While
    my reasons are primarily performance based, I think that most people
    would find the {-1} simpler to use as well.

    Ilia

    Sterling Hughes wrote:
    i hope not. this should be about what's cool for developers, the
    speed increase is not a compelling reason.. the debate is "does this
    make code easier to read/write/maintain?" I think it doesn't, and
    therefore am against it.

    -sterling

    On Mon, 1 Nov 2004 03:04:45 +0100, Marcus Boerger wrote:

    Hello Wez,

    well it would. However 5.1 aims to be a major speed improvement and that's
    what the idea is about.

    best regards
    marcus



    Monday, November 1, 2004, 2:29:46 AM, you wrote:

    Doesn't substr($a, -1) work ?
    --Wez.
    On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver wrote:

    It would reduce the errors I inevitably get
    whenever using a complex feature like substr(). The three choices:

    1) substr($a, strlen($a) - 1);
    2) $a{strlen($a) - 1}
    3) $a{-1}

    It's pretty obvious that the 3rd choice lowers the potential for all
    kinds of bugs (mistypign, wrong parameter name, incorrect parameter
    placement), and is much more readable. For those who already know how
    {} works in PHP, it's also obvious what it does at the first look
    without any speculation.
    --
    Best regards,
    Marcus mailto:helly@php.net

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Andrey Hristov at Nov 1, 2004 at 3:06 pm
    just to mention that there is substr_replace()
    php -r '$a="abc"; var_dump(substr_replace($a, "d", -1));'
    IMO at least there is no need for range like $a{-4:2}

    Andrey

    Ilia Alshanetsky wrote:
    IMO {-1} syntax is not only faster but simpler to use then the
    equivalent substr() (for read) or $a[strlen($a) - 1] (for write). While
    my reasons are primarily performance based, I think that most people
    would find the {-1} simpler to use as well.

    Ilia

    Sterling Hughes wrote:
    i hope not. this should be about what's cool for developers, the
    speed increase is not a compelling reason.. the debate is "does this
    make code easier to read/write/maintain?" I think it doesn't, and
    therefore am against it.

    -sterling

    On Mon, 1 Nov 2004 03:04:45 +0100, Marcus Boerger wrote:

    Hello Wez,

    well it would. However 5.1 aims to be a major speed improvement and
    that's
    what the idea is about.

    best regards
    marcus



    Monday, November 1, 2004, 2:29:46 AM, you wrote:

    Doesn't substr($a, -1) work ?
    --Wez.
    On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver wrote:

    It would reduce the errors I inevitably get
    whenever using a complex feature like substr(). The three choices:

    1) substr($a, strlen($a) - 1);
    2) $a{strlen($a) - 1}
    3) $a{-1}

    It's pretty obvious that the 3rd choice lowers the potential for all
    kinds of bugs (mistypign, wrong parameter name, incorrect parameter
    placement), and is much more readable. For those who already know how
    {} works in PHP, it's also obvious what it does at the first look
    without any speculation.

    --
    Best regards,
    Marcus mailto:helly@php.net

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Ilia Alshanetsky at Nov 1, 2004 at 3:20 pm
    Substr_replace() for the purpose of changing one char is like using a
    tank for a fly swatter, it may work but it is extremely inefficient.

    Ilia

    Andrey Hristov wrote:
    just to mention that there is substr_replace()
    php -r '$a="abc"; var_dump(substr_replace($a, "d", -1));'
    IMO at least there is no need for range like $a{-4:2}

    Andrey

    Ilia Alshanetsky wrote:
    IMO {-1} syntax is not only faster but simpler to use then the
    equivalent substr() (for read) or $a[strlen($a) - 1] (for write).
    While my reasons are primarily performance based, I think that most
    people would find the {-1} simpler to use as well.

    Ilia

    Sterling Hughes wrote:
    i hope not. this should be about what's cool for developers, the
    speed increase is not a compelling reason.. the debate is "does this
    make code easier to read/write/maintain?" I think it doesn't, and
    therefore am against it.

    -sterling

    On Mon, 1 Nov 2004 03:04:45 +0100, Marcus Boerger wrote:

    Hello Wez,

    well it would. However 5.1 aims to be a major speed improvement and
    that's
    what the idea is about.

    best regards
    marcus



    Monday, November 1, 2004, 2:29:46 AM, you wrote:

    Doesn't substr($a, -1) work ?
    --Wez.
    On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver <cellog@php.net>
    wrote:
    It would reduce the errors I inevitably get
    whenever using a complex feature like substr(). The three choices:

    1) substr($a, strlen($a) - 1);
    2) $a{strlen($a) - 1}
    3) $a{-1}

    It's pretty obvious that the 3rd choice lowers the potential for all
    kinds of bugs (mistypign, wrong parameter name, incorrect parameter
    placement), and is much more readable. For those who already know
    how
    {} works in PHP, it's also obvious what it does at the first look
    without any speculation.


    --
    Best regards,
    Marcus mailto:helly@php.net

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Andrey Hristov at Nov 1, 2004 at 4:07 pm
    So,
    the example wasn't clear but I stated with substr_replace() there is no need
    for ranges in {}.

    Andrey

    Ilia Alshanetsky wrote:
    Substr_replace() for the purpose of changing one char is like using a
    tank for a fly swatter, it may work but it is extremely inefficient.

    Ilia

    Andrey Hristov wrote:
    just to mention that there is substr_replace()
    php -r '$a="abc"; var_dump(substr_replace($a, "d", -1));'
    IMO at least there is no need for range like $a{-4:2}

    Andrey

    Ilia Alshanetsky wrote:
    IMO {-1} syntax is not only faster but simpler to use then the
    equivalent substr() (for read) or $a[strlen($a) - 1] (for write).
    While my reasons are primarily performance based, I think that most
    people would find the {-1} simpler to use as well.

    Ilia

    Sterling Hughes wrote:
    i hope not. this should be about what's cool for developers, the
    speed increase is not a compelling reason.. the debate is "does this
    make code easier to read/write/maintain?" I think it doesn't, and
    therefore am against it.

    -sterling


    On Mon, 1 Nov 2004 03:04:45 +0100, Marcus Boerger <helly@php.net>
    wrote:
    Hello Wez,

    well it would. However 5.1 aims to be a major speed improvement
    and that's
    what the idea is about.

    best regards
    marcus



    Monday, November 1, 2004, 2:29:46 AM, you wrote:

    Doesn't substr($a, -1) work ?


    --Wez.


    On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver <cellog@php.net>
    wrote:
    It would reduce the errors I inevitably get
    whenever using a complex feature like substr(). The three choices:

    1) substr($a, strlen($a) - 1);
    2) $a{strlen($a) - 1}
    3) $a{-1}

    It's pretty obvious that the 3rd choice lowers the potential for all
    kinds of bugs (mistypign, wrong parameter name, incorrect parameter
    placement), and is much more readable. For those who already
    know how
    {} works in PHP, it's also obvious what it does at the first look
    without any speculation.



    --
    Best regards,
    Marcus mailto:helly@php.net

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Sara Golemon at Nov 1, 2004 at 5:11 pm

    Substr_replace() for the purpose of changing one char is like using a
    tank for a fly swatter, it may work but it is extremely inefficient.
    the example wasn't clear but I stated with substr_replace() there is no
    need
    for ranges in {}.
    I like {$s,$l} and/or {$s:$e} for read, but I can see using that kinda
    syntax for write getting REALLY messy. So: -1 on write acces using {,} or
    {:} and if it doesn't work for write then making it work for read is
    inconsistent so -1 on the whole concept.

    Still +1 on $str{$negOffset} though, speed aside, it's readable and cute.

    -Sara
  • Shane Caraveo at Nov 1, 2004 at 6:41 pm

    Rasmus Lerdorf wrote:
    On Sun, 31 Oct 2004, moshe doron wrote:

    where the problem about 'taking it ever further'? I'm +1 for {-1}
    and more +1 for {-4,2} python likeness.

    That starts getting confusing.
    Having my python hat on...

    (some of this is just general comment after reading too much of this thread)

    Yeah, if that actually worked that way in python, it would be confusing.
    You cannot do:

    a="asdfghjkasdfghjk"
    a[-4:2]

    You get an empty string. That is because, as you said, it has to be
    start:end.

    a[2:-4] works and the result is of course "dfghjkasdf".

    You also cannot write to this:

    a[2:4]="asdf"

    That will throw an exception, as it should for apparent reasons.

    Negative index in strings and arrays are extremely usefull, and I use
    them a lot, but for some reason can never think why I use them. Thats
    probably because it's not tied to any particular type of operation.

    There also is this which is very useful for the reason that you do not
    have to calcuate length in your script (in the second two examples):

    a[:2] (grab the first two chars)
    a[2:] (everything after the first two chars)
    a[-2:] (grab the last two chars)

    For python, it's a great construct both for readability and performance.
    PHP would only benefit from the ability to use this. However, it
    should be of course, not be in a micro release. It is also unlikely
    many people will use it since it would not be backwards compatible code.

    Shane
  • Paul G at Nov 1, 2004 at 7:08 pm
    ----- Original Message -----
    From: "Shane Caraveo" <shane@caraveo.com>
    To: <internals@lists.php.net>
    Sent: Monday, November 01, 2004 1:41 PM
    Subject: Re: [PHP-DEV] Re: Negative string offset support


    --- snip --
    Having my python hat on...
    There also is this which is very useful for the reason that you do not
    have to calcuate length in your script (in the second two examples):

    a[:2] (grab the first two chars)
    a[2:] (everything after the first two chars)
    a[-2:] (grab the last two chars)

    For python, it's a great construct both for readability and performance.
    PHP would only benefit from the ability to use this. However, it
    should be of course, not be in a micro release. It is also unlikely
    many people will use it since it would not be backwards compatible code.
    imo, the reason this is so very useful in python is because you get to use
    it with strings, arrays and dictionaries (tuples as well?). while getting it
    for strings is better than nothing, having it work with everything would be
    very sweet from a syntactic sugar/easy to read/more expressive standpoint.

    realizing-that-i-might-just-have-killed-the-feature-request-by-asking-for-mo
    re-stuff-ly,
    paul
  • Greg Beaver at Oct 30, 2004 at 2:44 am

    Derick Rethans wrote:
    On Fri, 29 Oct 2004, Greg Beaver wrote:

    Ilia Alshanetsky wrote:
    I am wondering what are people's opinions on adding support for negative
    string offsets that could be used to access data from the end of a string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would break
    BC.
    I need this, +1

    How can you *need* this, you can use substr() just fine.
    I don't *need* PHP either. any other questions?

    Greg
  • Ilia Alshanetsky at Oct 30, 2004 at 5:56 am

    Derick Rethans wrote:
    How can you *need* this, you can use substr() just fine.
    Almost no peace of functionality in PHP in unique, some extensions
    duplicate core/standard functionality and vice versa. Usually the "core"
    offers a simpler access to a resource and full pledged extensions
    gives the full capabilities. The best example of this is streams,
    sockets extension and cURL.

    On a similar note, most users don't use even 1/2 the functionality PHP
    offers, does it mean we should remove those parts of the language or not
    have add them in the 1st place?

    Just because substr() or $a[strlen($a) - 1] would work, it does not
    mean they are the most optimal approaches. The change to permit negative
    string offsets would require @ most 2-3 line change in Zend and it would
    be trivial to write a series of tests to cover the affected code. We are
    not talking about a major change here.

    Ilia
  • Andrey Hristov at Oct 30, 2004 at 9:13 am

    Ilia Alshanetsky wrote:
    Derick Rethans wrote:
    How can you *need* this, you can use substr() just fine.

    Almost no peace of functionality in PHP in unique, some extensions
    duplicate core/standard functionality and vice versa. Usually the "core"
    offers a simpler access to a resource and full pledged extensions gives
    the full capabilities. The best example of this is streams, sockets
    extension and cURL.

    On a similar note, most users don't use even 1/2 the functionality PHP
    offers, does it mean we should remove those parts of the language or not
    have add them in the 1st place?

    Just because substr() or $a[strlen($a) - 1] would work, it does not
    mean they are the most optimal approaches. The change to permit negative
    string offsets would require @ most 2-3 line change in Zend and it would
    be trivial to write a series of tests to cover the affected code. We are
    not talking about a major change here.

    Ilia
    Privet Ilia,
    Andy mentioned that he tried in the past to separate {} and [] but after
    some unsuccess he left the idea of separating. So, the patch definitely
    won't be 2-3 lines of code.
    There are a lot of people which don't know about negative offsets at all,
    and use strlen() for calculations. Moving this feature to the language
    itself won't help them that much if just don't read the documentation (
    as they do).

    Andrey
  • Ilia Alshanetsky at Oct 30, 2004 at 3:45 pm

    Andrey Hristov wrote:
    Andy mentioned that he tried in the past to separate {} and [] but after
    some unsuccess he left the idea of separating. So, the patch definitely
    won't be 2-3 lines of code.
    I am well aware that at this point PHP has no separation between [] and
    {} as far as string offsets go. My initial suggestion was to add the
    support for negative offsets and not to limit it to a particular
    construct. Given that this is intended for strings only, I readily
    agreed with people who suggested that it should be available only for
    {}, assuming there was a separation.
    There are a lot of people which don't know about negative offsets at all,
    and use strlen() for calculations. Moving this feature to the language
    itself won't help them that much if just don't read the documentation (
    as they do).
    Almost any new function/construct/extension begins from obscurity. Even
    people who know about it won't use it till enough PHP versions have been
    released with it, because they'd up limit their apps to "latest and
    greatest".

    Ilia
  • Markus Fischer at Oct 31, 2004 at 12:23 am

    Ilia Alshanetsky wrote:
    I am well aware that at this point PHP has no separation between [] and
    {} as far as string offsets go. My initial suggestion was to add the
    support for negative offsets and not to limit it to a particular
    construct. Given that this is intended for strings only, I readily
    agreed with people who suggested that it should be available only for
    {}, assuming there was a separation.
    What happens to arrays when there's no difference between [] and {} ?

    $array[-1]
    $string[-1]

    This will confused people because $array[-1] actually wouldn't return the last element (it could, if we know the indices are only positive integers, but we can't assume when that when using arrays with arbitrary keys -> hashes).

    That seems problematic to me.

    - Markus
  • Sterling Hughes at Oct 29, 2004 at 7:34 pm
    why not add it with the {} operators then?

    -sterling

    On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky wrote:
    I am wondering what are people's opinions on adding support for negative
    string offsets that could be used to access data from the end of a string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would break BC.

    Ilia

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Cm at Oct 29, 2004 at 8:06 pm
    Exactly what I thought when reading the original post :)

    - Michael
    why not add it with the {} operators then?

    -sterling

    On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky wrote:
    I am wondering what are people's opinions on adding support for negative
    string offsets that could be used to access data from the end of a
    string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would break
    BC.

    Ilia

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Rasmus Lerdorf at Oct 29, 2004 at 8:06 pm
    Right, I was about to say that too. If we only did it for the {} operator
    it would encourage people to use that little-used operator thereby
    removing a source of confusion and at the same time the BC issues are
    minimal.

    -Rasmus
    On Fri, 29 Oct 2004, Sterling Hughes wrote:

    why not add it with the {} operators then?

    -sterling

    On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky wrote:
    I am wondering what are people's opinions on adding support for negative
    string offsets that could be used to access data from the end of a string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would break BC.

    Ilia

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Ilia Alshanetsky at Oct 29, 2004 at 8:07 pm
    Sure, I have no operator preference.

    Ilia

    Sterling Hughes wrote:
    why not add it with the {} operators then?

    -sterling

    On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky wrote:

    I am wondering what are people's opinions on adding support for negative
    string offsets that could be used to access data from the end of a string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would break BC.

    Ilia

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derick Rethans at Oct 29, 2004 at 11:04 pm

    On Fri, 29 Oct 2004, Sterling Hughes wrote:

    why not add it with the {} operators then?
    Yeah, [] is for arrays, {} for string indexes though I still think this
    should not be in, one can use substring for this. Something like a
    "negative string index" is IMO too much magic.

    Derick
  • Robert Cummings at Oct 29, 2004 at 11:27 pm

    On Fri, 2004-10-29 at 19:04, Derick Rethans wrote:
    On Fri, 29 Oct 2004, Sterling Hughes wrote:

    why not add it with the {} operators then?
    Yeah, [] is for arrays, {} for string indexes though I still think this
    should not be in, one can use substring for this. Something like a
    "negative string index" is IMO too much magic.
    Just as much magic as the negative start in substr() function. It would
    be consistent with substr() precedent of negative indexes counting
    backward from end of string. Also, everyone knows functions run slower
    than operators :)

    Cheers,
    Rob.
    --
    .------------------------------------------------------------.
    InterJinn Application Framework - http://www.interjinn.com |
    :------------------------------------------------------------:
    An application and templating framework for PHP. Boasting |
    a powerful, scalable system for accessing system services |
    such as forms, properties, sessions, and caches. InterJinn |
    also provides an extremely flexible architecture for |
    creating re-usable components quickly and easily. |
    `------------------------------------------------------------'
  • Derick Rethans at Oct 29, 2004 at 11:32 pm

    On Fri, 29 Oct 2004, Robert Cummings wrote:
    On Fri, 2004-10-29 at 19:04, Derick Rethans wrote:

    Yeah, [] is for arrays, {} for string indexes though I still think this
    should not be in, one can use substring for this. Something like a
    "negative string index" is IMO too much magic.
    Just as much magic as the negative start in substr() function. It would
    be consistent with substr() precedent of negative indexes counting
    backward from end of string.
    But substr() is a *function*, that's totally different from a language
    construct which should be a generic tool, not a specific one like Ilia
    is proposing here.
    Also, everyone knows functions run slower than operators :)
    *cough*bullshit argument*cough*

    Derick
  • Robert Cummings at Oct 29, 2004 at 11:57 pm

    On Fri, 2004-10-29 at 19:31, Derick Rethans wrote:
    On Fri, 29 Oct 2004, Robert Cummings wrote:
    On Fri, 2004-10-29 at 19:04, Derick Rethans wrote:

    Yeah, [] is for arrays, {} for string indexes though I still think this
    should not be in, one can use substring for this. Something like a
    "negative string index" is IMO too much magic.
    Just as much magic as the negative start in substr() function. It would
    be consistent with substr() precedent of negative indexes counting
    backward from end of string.
    But substr() is a *function*, that's totally different from a language
    construct which should be a generic tool, not a specific one like Ilia
    is proposing here.
    Also, everyone knows functions run slower than operators :)
    *cough*bullshit argument*cough*
    Well for the amount of times you need to traverse backward in a string
    it probably is a crap argument :) However it does indeed stand that
    operators are processed faster than functions I would wager due to the
    overhead of setting up parameters etc. Contrast is_null( $x ) versus $x
    === null, there's about 17% difference in speed. Similarly (0.0 + $x)
    takes almost half the time of floatval( $x ).

    Cheers,
    Rob.
    --
    .------------------------------------------------------------.
    InterJinn Application Framework - http://www.interjinn.com |
    :------------------------------------------------------------:
    An application and templating framework for PHP. Boasting |
    a powerful, scalable system for accessing system services |
    such as forms, properties, sessions, and caches. InterJinn |
    also provides an extremely flexible architecture for |
    creating re-usable components quickly and easily. |
    `------------------------------------------------------------'
  • Paul G at Oct 29, 2004 at 8:14 pm
    ----- Original Message -----
    From: "Ilia Alshanetsky" <ilia@prohost.org>
    To: <internals@lists.php.net>
    Sent: Friday, October 29, 2004 3:07 PM
    Subject: [PHP-DEV] Negative string offset support

    I am wondering what are people's opinions on adding support for negative
    string offsets that could be used to access data from the end of a string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would break
    BC.

    this, coupled with splicing, is very useful in python. i believe it would be
    very useful in php as well. agree with sterling's suggestion - it would
    enable all of the functionality, rather than some.

    paul
  • Andi Gutmans at Oct 29, 2004 at 10:37 pm
    We haven't yet separated the semantics of {} and []. It was always planned
    but never done.
    I'll put it on my TODO and hopefully will find some time to look into it.

    Andi
    At 04:13 PM 10/29/2004 -0400, Paul G wrote:

    ----- Original Message -----
    From: "Ilia Alshanetsky" <ilia@prohost.org>
    To: <internals@lists.php.net>
    Sent: Friday, October 29, 2004 3:07 PM
    Subject: [PHP-DEV] Negative string offset support

    I am wondering what are people's opinions on adding support for negative
    string offsets that could be used to access data from the end of a string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would break
    BC.

    this, coupled with splicing, is very useful in python. i believe it would be
    very useful in php as well. agree with sterling's suggestion - it would
    enable all of the functionality, rather than some.

    paul

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Alan Knowles at Oct 30, 2004 at 12:50 am
    echo $a{strlen($a)-1}; ? is that really that bad.

    I do worry that at present
    $a = "a string";
    $p = 0
    while( $p < strlen($p) )
    .. do stuff that could do $p-- or $p++ ....
    echo $a{$p};
    }

    at present that would produce a nice error if you went < 0.. easy to
    spot.. - if -ve was supported it could do unexpected stuff..

    Regards
    Alan

    Ilia Alshanetsky wrote:
    I am wondering what are people's opinions on adding support for
    negative string offsets that could be used to access data from the end
    of a string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would
    break BC.

    Ilia
  • Ilia Alshanetsky at Oct 30, 2004 at 6:20 am
    While you are correct that invalid offset in a string will produce an
    error message. This error message is E_NOTICE, given that our default
    INI error reporting level won't display those it's arguable that very
    few people will see them and consequently do something about it.
    echo $a{strlen($a)-1}; ? is that really that bad.
    It is not that bad, but it could be better. Basic tests I've ran show
    that using a strlen() is 30-40% slower and substr() is 20-25% slower
    then $a{-1}.

    Ilia

    Alan Knowles wrote:
    I do worry that at present
    $a = "a string";
    $p = 0
    while( $p < strlen($p) )
    .. do stuff that could do $p-- or $p++ ....
    echo $a{$p};
    }

    at present that would produce a nice error if you went < 0.. easy to
    spot.. - if -ve was supported it could do unexpected stuff..

    Regards
    Alan

    Ilia Alshanetsky wrote:
    I am wondering what are people's opinions on adding support for
    negative string offsets that could be used to access data from the end
    of a string.

    Ex. $a = "123"; echo $a[-1]; // would print 3

    I don't think we should do this for arrays, since -1 and similar are
    valid array keys, which means adding this support for arrays would
    break BC.

    Ilia
  • Ford, Mike at Nov 1, 2004 at 10:47 am
    To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm


    On 30 October 2004 02:03, Andi Gutmans wrote:

    Nah that patch won't do because it'll effect [] also.
    It's more complicated than that. I've tried separating them in the
    past and it was annoying (and didn't have time to finish it off).
    Well, according to the docs, the [] syntax is deprecated -- *if* the
    []and {} syntaxes are fully separated, and *if* functionality is
    added to the {} syntax only, wouldn't this be a good time to
    emphasize that deprecation and set an actual cutoff for it (such as
    PHP 6.0?)?

    Incidentally, I'd be about +100 (if my opinion counted for that
    much!) for $string{-1}, purely for readability -- any performance
    gain would be a bonus.
    At 05:51 PM 10/29/2004 -0700, Sara Golemon wrote:

    - People might want to take this even further and request {1,3},
    {-3,2} and the like. (This was expressed in the past when
    talking about this stuff)
    They might... and the response to that is that it's a more
    siginificant modification/glut of the exisiting code than merely
    allowing negative offsets. The fact is allowing negative string
    offsets via the {} operator involves changing one line, and it's no
    major waste of CPU cycles. Full substr()esque behavior would be
    more bloat-intensive of course and I'd be inclined to side against
    that.
    I'd also be +several for folding substr() behaviour into the {} string
    syntax -- I've often thought that if I ever have time to muck about
    with the source, I'd like to make that my first little project.

    (Incidentally, re another post, I'd expect $string{$m, $l} to be the
    substring clone, and $string{$m:$n} to be "from offset $m to offset $n"
    syntax -- and, personally, I'd like to see both. But then, I'm a
    programmer with over 20 years experience, so probably not your typical
    PHP user at all, and I can quite see the argument about not cluttering
    up PHP with potentially obscure syntaxes. So I'll shut up now! ;)

    Cheers!

    Mike

    ---------------------------------------------------------------------
    Mike Ford, Electronic Information Services Adviser,
    Learning Support Services, Learning & Information Services,
    JG125, James Graham Building, Leeds Metropolitan University,
    Headingley Campus, LEEDS, LS6 3QS, United Kingdom
    Email: m.ford@leedsmet.ac.uk
    Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211

Related Discussions

People

Translate

site design / logo © 2022 Grokbase