Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114625
Message-ID: <F11B1486-A90C-49CA-802E-C2C308AAB76C@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_65786917-E141-4F80-899A-7DF13C5609FD"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
Date: Wed, 26 May 2021 15:35:58 -0400
In-Reply-To: <CAESVnVqGdNjbC=5R9J9nXd28U-ANvGbywhizN6ZV3cZ_0X6QXg@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
To: Sara Golemon <pollita@php.net>,
 Marco Pivetta <ocramius@gmail.com>
References: <CAOfzkkxbS6CQidg4-uai42PPRPHfWWL9UZTd+zDgspXsFSr5zg@mail.gmail.com>
 <CAESVnVqGdNjbC=5R9J9nXd28U-ANvGbywhizN6ZV3cZ_0X6QXg@mail.gmail.com>
Subject: Re: [PHP-DEV] A little syntactic sugar on array_* function calls?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_65786917-E141-4F80-899A-7DF13C5609FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On May 26, 2021, at 2:34 PM, Sara Golemon <pollita@php.net> wrote:
>=20
> What I don't like about the specific proposal is that it's just a =
little
> too magic in its function selection and argument mapping.  There's =
also the
> fact that it doesn't leave room to improve specifics about the
> implementations of the methods.  I'd much rather seen an `Array` class
> defined with specific methods declared on it. =20

Wouldn't an `Array` class necessarily result in array-incompatible =
pass-by-reference semantics, which is one of the same issues with =
userland using ArrayObject as an array replacement?


> On May 26, 2021, at 7:51 AM, Marco Pivetta <ocramius@gmail.com> wrote:
>=20
> On Wed, May 26, 2021 at 1:03 PM Mike Schinkel <mike@newclarity.net =
<mailto:mike@newclarity.net>> wrote:
>=20
>=20
> > On May 25, 2021, at 6:28 PM, Iv=C3=A1n Arias <txigreman@hotmail.com =
<mailto:txigreman@hotmail.com>> wrote:
> >=20
> > Hi all,
> >=20
> > It sounds like scalar objects by Nikita:  =
https://github.com/nikic/scalar_objects =
<https://github.com/nikic/scalar_objects>
>=20
> Yes, but Nikita wrote this note about technical limitations at the =
bottom of the repo README:
>=20
> Due to technical limitations, it is not possible to create mutable =
APIs for primitive types. Modifying $self within the methods is not =
possible (or rather, will have no effect, as you'd just be changing a =
copy).
>=20
> Sounds like a big **advantage**?=20

Yes, it is a big advantage.

Except for when it is not.

-Mike=

--Apple-Mail=_65786917-E141-4F80-899A-7DF13C5609FD--