Greetings geeks,
This topic still lacks a defined conclusion. There are several rumors that something was decided, but I can't confirm this without archived proof. Here's the code:
$str = "I am an array of characters, but still a string.";
echo $str[3]; // Documented as correct since 2006
echo $str{3}; // Documented as deprecated since 2006, but still no E_DEPRECATED error
We discussed this uninteresting topic back in 2008 here, which includes the timeline:
There was no conclusion, and the thread went off topic. So because code speaks louder than words, the following will happen if this does not receive an alternative conclusion here:
- Both will be considered fine, where neither is deprecated. Both will be documented as proper.
One opinion is it should remain deprecated but without an E_DEPRECATED error, but I'm unsure how that makes sense. To me that says it's not deprecated, but rather, is discouraged (but still for unknown reasons). Anyway, thoughts?
Also, Andi mentioned[1] the possibility of optimizing {} for string use (the original intent) in which case keeping {} would be wise.
[1] http://markmail.org/message/qisqdheeyoccfydh
[2] Related bug: http://bugs.php.net/52254
Regards,
Philip
Hello,
Greetings geeks,
Also, Andi mentioned[1] the possibility of optimizing {} for string use (the original intent) in which case keeping {} would be wise.
It was over two years ago I commented on my interest in keeping {} and
offering/exploring the potential to performance or feature
improvements to the syntax, I still have the same opinion personally.
-Chris
Greetings geeks,
This topic still lacks a defined conclusion. There are several rumors that something was decided, but I can't confirm this without archived proof. Here's the code:
$str = "I am an array of characters, but still a string.";
echo $str[3]; // Documented as correct since 2006
echo $str{3}; // Documented as deprecated since 2006, but still noE_DEPRECATEDerrorWe discussed this uninteresting topic back in 2008 here, which includes the timeline:
- http://php.markmail.org/thread/nm7n57ns23mwoshw
There was no conclusion, and the thread went off topic. So because code speaks louder than words, the following will happen if this does not receive an alternative conclusion here:
- Both will be considered fine, where neither is deprecated. Both will be documented as proper.
For no real, technical, reason, (just what my gut wants, and I tend to
listen to it) I would prefer both to continue being equal* without any
deprecation (E_DEPRECATED or just word-of-mouth).
- They're not always interchangeable: this may be sliding off-topic
(so feel free not to address it in this thread) but I'd quite like the
curly-brace syntax to be available for the function array
dereferencing which was added to trunk if only to keep things
consistent.
One opinion is it should remain deprecated but without an
E_DEPRECATEDerror, but I'm unsure how that makes sense. To me that says it's not deprecated, but rather, is discouraged (but still for unknown reasons). Anyway, thoughts?Also, Andi mentioned[1] the possibility of optimizing {} for string use (the original intent) in which case keeping {} would be wise.
[1] http://markmail.org/message/qisqdheeyoccfydh
[2] Related bug: http://bugs.php.net/52254Regards,
Philip
Greetings geeks,
This topic still lacks a defined conclusion. There are several rumors that something was decided, but I can't confirm this without archived proof. Here's the code:
$str = "I am an array of characters, but still a string.";
echo $str[3]; // Documented as correct since 2006
echo $str{3}; // Documented as deprecated since 2006, but still noE_DEPRECATEDerrorWe discussed this uninteresting topic back in 2008 here, which includes the timeline:
There was no conclusion, and the thread went off topic. So because code speaks louder than words, the following will happen if this does not receive an alternative conclusion here:
- Both will be considered fine, where neither is deprecated. Both will be documented as proper.
One opinion is it should remain deprecated but without an
E_DEPRECATEDerror, but I'm unsure how that makes sense. To me that says it's not deprecated, but rather, is discouraged (but still for unknown reasons). Anyway, thoughts?Also, Andi mentioned[1] the possibility of optimizing {} for string use (the original intent) in which case keeping {} would be wise.
[1] http://markmail.org/message/qisqdheeyoccfydh
[2] Related bug: http://bugs.php.net/52254Regards,
Philip
You're right - it doesn't make sense.
My vote goes to leave it as-is.
Mark Skilbeck
mahcuz.com | gtk.php.net | pecl.php.net/cairo | docs.php.net
Greetings geeks,
This topic still lacks a defined conclusion. There are several rumors that something was decided, but I can't confirm this without archived proof. Here's the code:
$str = "I am an array of characters, but still a string.";
echo $str[3]; // Documented as correct since 2006
echo $str{3}; // Documented as deprecated since 2006, but still noE_DEPRECATEDerrorWe discussed this uninteresting topic back in 2008 here, which includes the timeline:
There was no conclusion, and the thread went off topic. So because code speaks louder than words, the following will happen if this does not receive an alternative conclusion here:
- Both will be considered fine, where neither is deprecated. Both will be documented as proper.
One opinion is it should remain deprecated but without an
E_DEPRECATEDerror, but I'm unsure how that makes sense. To me that says it's not deprecated, but rather, is discouraged (but still for unknown reasons). Anyway, thoughts?Also, Andi mentioned[1] the possibility of optimizing {} for string use (the original intent) in which case keeping {} would be wise.
[1] http://markmail.org/message/qisqdheeyoccfydh
[2] Related bug: http://bugs.php.net/52254Regards,
Philip
You're right - it doesn't make sense.
My vote goes to leave it as-is with no deprecation, or having it
deprecated and actually emitting the E_DEPRECATED notice.
Mark Skilbeck
mahcuz.com | gtk.php.net | pecl.php.net/cairo | docs.php.net
I think leave both ways, because it's really much of the code uses actually
{4} rather than [4] for strings.
But please do the substr functionality as it was suggested a few years
before. That makes perfect sense :)
I think leave both ways, because it's really much of the code uses actually
{4} rather than [4] for strings.
But please do the substr functionality as it was suggested a few years
before. That makes perfect sense :)
Are there any further thoughts on this thread? Even though {} is a
small and likely uninteresting topic, it would be nice to actually
(finally, until we change our minds) come to a conclusion and unite
the code with the docs.
I think leave both ways, because it's really much of the code uses actually
{4} rather than [4] for strings.
But please do the substr functionality as it was suggested a few years
before. That makes perfect sense :)Are there any further thoughts on this thread? Even though {} is a
small and likely uninteresting topic, it would be nice to actually
(finally, until we change our minds) come to a conclusion and unite
the code with the docs.
Was going to wait a week (we're close enough) but this thread (and past ones) decided that $str{42} is no longer deprecated, with hope that the syntax will be optimized by Chris, Andi, or whoever scratches that itch in the future. The documentation will be updated.
Regards,
Philip