Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49778
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain roshambo.org from 209.85.160.42 cause and error)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 22 Sep 2010 14:34:03 -0700
Message-ID: <9CE5BB6D-2BBC-4171-AF43-01A27EBDE1EF@roshambo.org>
Cc: Andi Gutmans <andi@zend.com>
To: Internals Internals <internals@lists.php.net>
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: deprecation status of $str{42} versus $str[42], revisited
From: philip@roshambo.org (Philip Olson)

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 =3D "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:

  - 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.

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.=20

[1] http://markmail.org/message/qisqdheeyoccfydh
[2] Related bug: http://bugs.php.net/52254

Regards,
Philip