Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126022
Date: Thu, 21 Nov 2024 10:56:17 +0000
To: Christian Schneider <cschneid@cschneid.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Discussion] Make objects unpackable by default
Message-ID: <0AUU5hqlTPa2cS3cb6pCTqbbQu6vz3NzuqjOgwbYyMjpu2fPSgql4BNsRqSCw2jGXH8vHPZKf7OBuvITs1mw815yXi6XfaN3M-mpXXH9cWw=@gpb.moe>
In-Reply-To: <B9F24C2E-BAB9-4453-9EDF-E368307055BC@cschneid.com>
References: <CALWFqqCWV6bzJ0wQud5uH9U82JtNGOqjTOad-w7PVoZ4yn3YVQ@mail.gmail.com> <CADyq6s+rctWKjQG2g-sy_tWibdyesLKkuxCwNCyor1_KhBnpaQ@mail.gmail.com> <C62F7404-7472-4A01-BD43-C3C5A667DFC5@cschneid.com> <3dcc5393-6ce7-465c-abe6-ecb687b0f369@app.fastmail.com> <XaOoWJgnX8SscFzrrr_NpUlek3W0Q9Gqx3YcJcnydI6SWs6ppdXEAYj6FJoy5XsnEdOk18-8eX4vka_Qb4Be9KWTE51y7JVorQrk5YROu4U=@gpb.moe> <B9F24C2E-BAB9-4453-9EDF-E368307055BC@cschneid.com>
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, 21 November 2024 at 10:05, Christian Schneider <cschneid@cschn=
eid.com> wrote:

> Am 14.11.2024 um 22:27 schrieb Gina P. Banyard internals@gpb.moe:
>=20
> > Agreed, this bites us constantly when needing to reason about what an "=
object" is in PHP.
> > Similar to array it mixes the concept of a struct, with that of a refer=
ence value, and "overloading" various behaviours (e.g. iterators and ArrayA=
ccess).
> > It is extremely simple to go from foreach ($object as $prop) {} to fore=
arch(get_object_vars($object) as $prop) {}
> > and mandating this would resolve a lot of complexity, be that from the =
perspective of what is "possible" or not to do, and from an engine PoV.
>=20
>=20
> Is there (currently) a difference between
> foreach ($obj ...)
> and
> foreach (get_object_vars($obj) ...)?
>=20
> If there is then the migration is not always "extremely" simple, no?
> If there isn't then we can simply define that from now on the former is e=
quivalent to the second one and ignore future changes to visibility, hooks =
etc.
>=20
> My main point is that over the last years a lot of (for our code unnecess=
ary) complexity was added but I hardly complained because other people have=
 other needs. I just ask for similar consideration in return when stripping=
 stuff.


There is not, see: https://3v4l.org/T7tSu/rfc#vgit.master

Best regards,

Gina P. Banyard