Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56521
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.42 as permitted sender)
MIME-Version: 1.0
Sender: ekneuss@gmail.com
In-Reply-To: <CAEZPtU60zyunA1xNtm0P+Fs2oSr399Ea-nUQwUY4G86bUzy2xQ@mail.gmail.com>
References: <20111123015008.GA12933@panix.com>
	<CACQesk6UuGUgyJz3hsGVE0crJx3GCkjTTpLb4xNGTm1goLzO8Q@mail.gmail.com>
	<20111123023108.GA172@panix.com>
	<CACQesk5kj=4kzvTDiLL1oOLBXZrn4WdUcLXdbyMLTa=OdhGTcw@mail.gmail.com>
	<4ECCB549.904@lsces.co.uk>
	<4ECCBC56.3050602@sugarcrm.com>
	<20111123141408.GA11940@panix.com>
	<20111123153100.GB13420@panix.com>
	<CAKUjMCVkmd2+=K9n6XVMeKvMCaMwORQN-3phA2CqZVjXBChPSg@mail.gmail.com>
	<CAEZPtU60zyunA1xNtm0P+Fs2oSr399Ea-nUQwUY4G86bUzy2xQ@mail.gmail.com>
Date: Wed, 23 Nov 2011 19:34:40 +0100
Message-ID: <CACQesk49SeO9YNvt3WxKrr_i+8Q0wSMotdi=LynhLPf+HMD1ig@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: RQuadling@gmail.com, Daniel Convissor <danielc@analysisandsolutions.com>, 
	Stas Malyshev <smalyshev@sugarcrm.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
From: colder@php.net (Etienne Kneuss)

Hi,

What people seem to have trouble with here is not that $string[0][0]
== $string[0], but rather that $string['index'] === $string[0]...

But as many people said, it is just how type juggling want: string
index? Get me an int => 0.

I believe the change introduced in 5.4 makes sense, the previous way
it worked made no sense and was simply an anomaly.

It is clear from this thread that the confusion comes from strings as
string offsets, something "totally" different, but changing that would
be a much bigger BC break I guess.

Best,

On Wed, Nov 23, 2011 at 19:22, Pierre Joye <pierre.php@gmail.com> wrote:
> On Wed, Nov 23, 2011 at 6:58 PM, Richard Quadling <rquadling@gmail.com> wrote:
>
>> Just looking for any test relating to isset() to see what tests will now fail.
>>
>> Neither of the isset() tests ext/standard/tests/general_functions look
>> at arrays with associative indices.
>>
>> The behaviour with regard to unavailable associative indices has no tests.
>>
>> But using loose typing as a fallback for non existent keys seems
>> really really wrong.
>>
>> Especially if the key is a constant. On what planet should ...
>>
>> isset($arr['exists']['test_existance']) should become isset($arr['exists'][0])
>>
>> That just seems really wrong and the work around is awful.
>
> That's exactly why I stoped to use this syntax a long time ago. And I
> was in favor to deprecate it and actually remove it the next major
> release (6 that is). But that's another discussion.
>
> Unless I'm mistaken it seems that we have a clear and vicious BC break
> here, the kind of changes that are annoying to catch and does not
> bring a lot of benefits to PHP (given the actual usage of this
> syntax). I would go with a revert, add tests and never change this
> behavior again. It is a confusing enough topic.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Etienne Kneuss
http://www.colder.ch