Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114654
Message-ID: <CD1CCD71-B0DE-48A5-A18F-E23E90B083F7@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_ECEB1DD7-672D-4E71-8436-F56F6AA5D429"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
Date: Thu, 27 May 2021 21:11:07 -0400
In-Reply-To: <CAG4FTXyz-EkWPTbaBXaKLSFmaaidpLokuuzsg_FbMK0YwDEPEA@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
To: Hendra Gunawan <the.liquid.metal@gmail.com>
References: <CAOfzkkxbS6CQidg4-uai42PPRPHfWWL9UZTd+zDgspXsFSr5zg@mail.gmail.com>
 <CABAhh3ER9_Pv6g7jANQ-qoTE6DmTLHWTv6Ggjr+qvnbXqXBB0w@mail.gmail.com>
 <CANS-=pc0qe7aRLAPxSjj+AT46m8Y=ARB4L8AwESKmiQVK=dEJw@mail.gmail.com>
 <CABAhh3GfC+69FoGzUQxC+O3MhiETgN_s4edYQL2FUndrex5-JA@mail.gmail.com>
 <CAOfzkkxSw7euY_nhOVo+gHx8FXjycVey84j+YiEZMXpPAkvKmA@mail.gmail.com>
 <CABAhh3GwwmsyyFwbwN6OHFKCT1zkTdBmmKcCvSC=WxxAwyDh+A@mail.gmail.com>
 <CAG4FTXySSCV8io6kkgExAewj+DG2eGfm2r=Vg9Vr6t+M2xQx2A@mail.gmail.com>
 <PA4PR02MB68005CAC217AD3B0EAB5DCE7B8259@PA4PR02MB6800.eurprd02.prod.outlook.com>
 <E5A7BE78-D8E2-45AF-B2B4-40538DFEA57F@newclarity.net>
 <CAG4FTXyz-EkWPTbaBXaKLSFmaaidpLokuuzsg_FbMK0YwDEPEA@mail.gmail.com>
Subject: Re: [PHP-DEV] A little syntactic sugar on array_* function calls?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_ECEB1DD7-672D-4E71-8436-F56F6AA5D429
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On May 26, 2021, at 7:44 PM, Hendra Gunawan =
<the.liquid.metal@gmail.com> wrote:
>=20
> Hello.
>=20
>>=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
>=20
> If it is solved, this is a great accomplishment for PHP. But I think
> scalar object is not going anywhere in the near future. If you are not
> convinced, please take a look
> =
https://github.com/nikic/scalar_objects/issues/20#issuecomment-569520181.

Nikita's comment actually causes me more questions, not fewer.

Nikita says "We need to know that $a[$b][$c is an array in order to =
determine that the call should be performed by-reference. However, we =
already need to convert $a, $a[$b] and $a[$b][$c] into references before =
we know about that." =20

How then are we able to do the following?:

$a[$b][$c][] =3D 1;

How also can we do this:

byref($a[$b][$c]);
function byref(&$x) {
    $x[]=3D 2;
}

See https://3v4l.org/aPvTD <https://3v4l.org/aPvTD>

I assume that in both my examples $a[$b][$c] would be considered an =
"lvalue"[1] and can be a target of assignment triggered by either the =
assignment operator or calling the function and passing to a by-ref =
parameter. =20

[1] =
https://en.wikipedia.org/wiki/Value_(computer_science)#Assignment:_l-value=
s_and_r-values

So is there a reason that -> on an array could not trigger the same?  Is =
Nikita saying that the performance of those calls performed by-reference =
would not matter because they are always being assigned, at least in the =
former case, but to do so with array expressions would be problematic? =
(Ignoring there is no code in the wild that currently uses the -> =
operator, or does that matter?)

I ask honestly to understand, and not as a rhetorical question.

Additionally, if the case of updating an array variable is not a problem =
but updating an array expression is a problem then why not just limit =
the -> operator to only work on expressions for immutable methods and =
require variables for mutable methods?  I would think should be easy =
enough to throw an error for those specific "methods" that would be =
mutable, such as shift() and unshift() if $a[$b][$c]->shift('foo') were =
called?

Or maybe just completely limit using the -> operator on array variables. =
Don't work on any array expressions for consistency. There is already =
precedence in PHP for operators that work on variables and not on =
expressions:  ++, --, and &.

IF we can get a thumbs up from Nikita that one of these would actually =
be possible then I think the next step should be to write up a list of =
proposed array methods that would be implemented to support the -> =
operator with arrays and put them in an RFC, and to flesh out any edge =
cases.

-Mike



--Apple-Mail=_ECEB1DD7-672D-4E71-8436-F56F6AA5D429--