Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124443
Date: Tue, 16 Jul 2024 02:27:25 +0000
To: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers
Message-ID: <RD_mG3zRTgWHxE0U7BTUa_c7g4K20PRgWyPaOUms-ZlRCKTKbJ1Y1iGX1wMwMs12smk3Mi-KIq3wOV22Zj_BDHrJtwRU3h3kLg-21SZstWE=@gpb.moe>
In-Reply-To: <mhbeurk_htxbQxzIEs98wQoR8Xczf-L7L8aCAIVhATD7wQiEUJwpAYxYS-llyac0pN761mnQJfpVQcDUoXAgasaWpWylpt6LE-I2oM4zrbk=@gpb.moe>
References: <mhbeurk_htxbQxzIEs98wQoR8Xczf-L7L8aCAIVhATD7wQiEUJwpAYxYS-llyac0pN761mnQJfpVQcDUoXAgasaWpWylpt6LE-I2oM4zrbk=@gpb.moe>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Thursday, 4 July 2024 at 14:52, Gina P. Banyard <internals@gpb.moe> wrot=
e:

> Hello internals,
>=20
> I would like to formally open the discussion on an RFC I've been working =
on for the past year:
> https://wiki.php.net/rfc/container-offset-behaviour
>=20

Hello internals,

Ilija did a review of the RFC and pointed out some good questions and remar=
ks.

I've clarified, and amended the implementation, that ArrayAccess extends Di=
mensionReadable, DimensioWriteable, and DimensionUnsettable.

I've added to the RFC the deprecation of using integer offsets when using A=
rrayObject with a backing object, as it turns out supporting this adds a lo=
t of complexity in the engine that would be great to remove.

One of the new warnings the RFC introduces is when using a bogus value as a=
 container in isset()/empty() other than `null` which shortcuts.
This shouldn't cause many issues, except possibly if the container is `fals=
e`, as it may be the result from an internals function call which returns f=
alse on failure instead of null.
The question is if `false` should have the same exemption as `null`?

The behaviour around the increment and decrement operators is slightly unfo=
rtunate.
Incrementing an array offset or object property is treated more like a read=
-write operation, however, due to the lack of VM opcodes, it is treated lik=
e a fetch for object offsets.
After discussion with Ilija it seems wise to make this an Error for now so =
that we can support it properly in the future, and have the increment obser=
vable via the offsetSet() method.

There are still a couple of questions around the behaviour of ArrayObject w=
ith property hooks that I need to look into, especially around the current =
ArrayObject behaviour with ignoring the __set() and __get() magic methods.

The final question, which is somewhat tricky, is how to deal with auto-vivi=
fication?
The gist can be explained with the following code:

$obj =3D new Vector();
$ref =3D &$obj[0];
var_dump($ref);

$obj[1][] =3D 'append';
$obj[2][50] =3D 'set-to-offset';

For arrays, $ref would be NULL
And when nesting them, the "null" auto-magically becomes an array.
However, for objects it is not clear what to do, if the fetch() method crea=
tes an object,
then the initial $ref would already have a auto-vivified container.
However, if NULL is returned, then the nested append and offset write would=
 not auto-vivify a nested Vec container, but a standard PHP array.

I currently have a crude prototype where, in the nested dimension case, I i=
nstantiate a new object of the same type,
but this doesn't call the constructor (which I could do), but passing argum=
ents to it is impossible.
Another solution is to add another interface, e.g. Autovivificapable, which=
 would define an autovivify() method which would be called in those instanc=
es.
Does anyone have any opinions about this?

I have also slightly amended the RFC and added a BC break recap section.
Reminder, the RFC on the Wiki is located here:
https://wiki.php.net/rfc/container-offset-behaviour
And on GitHub here:
https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.=
md


Best regards,

Gina P. Banyard