Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91208
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
To: PHP internals <internals@lists.php.net>
References: <56A3A01F.1020500@php.net> <56BB4A5F.3060906@php.net>
 <56BC29C8.9070308@gmail.com>
 <CAGa2bXaJ1dphqr8MXWXtUkicx1eP-o21SLQtf_MxoVb2o823wg@mail.gmail.com>
 <56BC3372.1010308@gmail.com>
 <CAGa2bXbWnLkp3mfQBNbOxJxy8U0hNBA7e_RbiekJrfC4YFEgbg@mail.gmail.com>
 <56BC7BB6.6070705@gmx.de> <56BC829C.1040608@gmail.com>
 <CAF+90c_SzTdr-xrPhB4F4R2FAPkC0NRmVu4oEt1tR=dK5q4e8Q@mail.gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>
Message-ID: <56BCA158.9060005@gmail.com>
Date: Thu, 11 Feb 2016 14:57:28 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c_SzTdr-xrPhB4F4R2FAPkC0NRmVu4oEt1tR=dK5q4e8Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Generalize support of negative string offsets
From: rowan.collins@gmail.com (Rowan Collins)

Nikita Popov wrote on 11/02/2016 13:14:
> The issue here is not an inherent problem with string offsets, it's 
> simply yet another artifact of PHP's overly lenient nature. If I 
> create an IntArray class that implements ArrayAccess, I don't think 
> you would be much surprised if doing $intArray[$i] = "123abc" would 
> end up storing the value int(123), as this just conforms to PHP's 
> usual silent, lossy type conversion semantics. It's the same with 
> string offsets, just with the conversion happening from string to 
> single-character-string.

Eh, I can see the logic, but there is no such type as "single-character 
string"; that's why I said PHP's type system was to blame - if there was 
a "char" type, things become simpler to explain:
- the assignment case would be a case of implicit conversion from string 
to char
- the $foo[0][0] case could give an error that you can't offset a char, 
and "$bar = $foo[0]; echo $bar[0];" would be able to give the same error

I'd like to stress that these are just a couple of examples; I'm sure 
there are other "anomalies".

> Just having a different syntax, writing $foo{0} = 'zzz'  instead of 
> $foo[0] = 'zzz'  does not make the implicit truncation behavior any 
> more obvious or reasonable.

No, but it gives a general warning to the reader that this is a bit like 
array access, but not quite.

> If we want to actually make it less confusing, what we should do is 
> throw a warning if such a truncation occurs. And that's something that 
> can be done independently of syntax.

Agreed.

> Instead we should strive to make these things work as expected.

Agreed for the cases where it is obvious what is expected. Sometimes, 
though, I think it is not reasonable to expect the same behaviour as for 
an array, and so "striving to make string offsets work well" and 
"striving to make string offsets work the same as array offsets" are 
different, and possibly conflicting, goals.

Regards,
-- 
Rowan Collins
[IMSoP]