Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96738
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <E6.F9.07826.3490E185@pb1.pair.com>
References: <E6.F9.07826.3490E185@pb1.pair.com>
Date: Sun, 6 Nov 2016 05:55:30 +0900
Message-ID: <CAGa2bXZ6y6hKbUZuJecq8pAMZ=dp0HxKpBbEKajagqNYfzgGMw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] Convert numeric keys in object/array casts
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Andrea,

On Sun, Nov 6, 2016 at 1:30 AM, Andrea Faulds <ajf@ajf.me> wrote:
> Two weeks have passed since this RFC was put to discussion here, and no
> significant issues have cropped up. Therefore, I'm going to put it to a vote
> for inclusion in PHP 7.2.
>
> Voting starts today, 2016-11-05, and ends the Monday after next, 2016-11-14.
>
> The RFC and voting widget can be found here:
> https://wiki.php.net/rfc/convert_numeric_keys_in_object_array_casts
>
> It's a normal 2/3 majority required vote.

In short, array int index is converted to string numeric name
property, vice versa. Correct?

At first, I thought this is good idea, but it seems we are better to
allow "string integer" array key access (array_get/set_var(),
perhaps) and change other related features accordingly.

Currently, inaccessible value could happen in array due to "int
like string conversion to int" also.

https://3v4l.org/EpDuo

Line 9:
  var_dump($tmp, $tmp[0], $tmp['0']);
outputs
array(4) {
  [0]=>
  int(5)
  [1]=>
  int(6)
  [2]=>
  int(7)
  ["0"]=>
  string(3) "zzz" // <== String '0' indexed element is Inaccessible
}
int(5)
int(5) // <== Only long index 0 can be accessed


Either before or after RFC has pros and cons. For instance, proposed
change will require string casts for numeric property iteration, correct?

for($i=0; $i < 100; $i++) {
   $str_i = (string)$i;    // <== "int" key to "string" key conversion
                                // requires cast.
   echo $obj->{$str_i}; // This kind of expression with int/int like string
                                // index is not allowed now, but this
                                // could be valid.
                                // https://3v4l.org/e5L1T
}

Another cons after RFC is BC that
$arr[0] = 123;
$obj=(object)$arr;
$obj->{0} became $obj->{'0'}


Simply allowing access to "numeric string index and long index" for
_both_ array and object seems cleaner resolution for problems we have.
(Object allows distinct access to 0 and '0' indexes already, so make
array allow to access 0 and '0' indexed element.)

e.g
// There is no way to get string '0' index element now, so add
// array_get_var();
$obj->{0} === $arr[0];
$obj->{'0'} === array_get_var($arr, '0'); // Get string '0' indexed value

// Int and string index can have distinct value
$arr[0] !== $arr['0'];
$obj->{'0'} !== $arr[0];
$obj->{0} !== array_get_var($arr, '0');
$obj->{0} !== $obj->{'0'};

// Currently, we don't have way to set string '0' indexed element except
// converting object with string '0' index (e.g.  $obj->{'0'} = 123;)
//  to array. So implement array_set_var() to allow array to have
// string '0' indexed element.
array_set_var($arr, '0', 123); // Set string '0' indexed value 123
$obj = (object)$arr;
$ojb->{'0'} === array_get_var($arr, '0');


Making array accessible to "string int index" and reorganize other features
accordingly seems result in more consistent spec.

What do you think?


I found interesting behaviors while testing. I don't think I have good
understanding of this issue yet, please point out if I
miss/misunderstand something.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net