Newsgroups: php.internals,php.internals
Path: news.php.net
Xref: news.php.net php.internals:49784 php.internals:49785
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Philip Olson <philip@roshambo.org>
Message-ID: <4C9BADDD.3010201@gmail.com>
Date: Thu, 23 Sep 2010 20:43:25 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
CC: Internals Internals <internals@lists.php.net>, 
 Andi Gutmans <andi@zend.com>
References: <9CE5BB6D-2BBC-4171-AF43-01A27EBDE1EF@roshambo.org>
In-Reply-To: <9CE5BB6D-2BBC-4171-AF43-01A27EBDE1EF@roshambo.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: deprecation status of $str{42} versus $str[42], revisited
From: markskilbeck@gmail.com (Mark Skilbeck)

On 22/09/10 22:34, Philip Olson wrote:
> 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:
>
>    - 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.
>
> [1] http://markmail.org/message/qisqdheeyoccfydh
> [2] Related bug: http://bugs.php.net/52254
>
> Regards,
> 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