Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122620
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-251-g8332da0bf6-fm-20240305.001-g8332da0b
Precedence: bulk
MIME-Version: 1.0
Message-ID: <0cce4ac2-b50f-420e-aa7e-7705f0c61629@app.fastmail.com>
In-Reply-To: 
 <XaVRjsHCU2LdoJFqTvzS0BapaYrCnZLpEKo3N5tju6V3nawc6fQn_gsMh_Vjc9SZxRnKBdKYyl-WWKf8qjn7L_7ceqlV_xehfL5VL3Qu9V4=@gpb.moe>
References: 
 <1MzJ8G_MuG-LJsMSoGDIRBmSODjO4hxPACqMoQYfx83MS-du6sskpNLJ45HnzPYMoUNkXyGiZEUAtFk-uyeGDv_Kwg6Qgtod05pXCQH-8M8=@gpb.moe>
 <afccf689-7b0d-4758-9b11-c532775bd34f@app.fastmail.com>
 <XaVRjsHCU2LdoJFqTvzS0BapaYrCnZLpEKo3N5tju6V3nawc6fQn_gsMh_Vjc9SZxRnKBdKYyl-WWKf8qjn7L_7ceqlV_xehfL5VL3Qu9V4=@gpb.moe>
Date: Tue, 12 Mar 2024 08:19:16 +0100
To: "Gina P. Banyard" <internals@gpb.moe>,
 "Larry Garfield" <larry@garfieldtech.com>
Cc: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Pre-RFC] Improve language coherence for the behaviour of
 offsets and containers
Content-Type: multipart/alternative;
 boundary=00d33a1a3fc84430a6ab884adc331813
From: rob@bottled.codes ("Rob Landers")

--00d33a1a3fc84430a6ab884adc331813
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Mar 12, 2024, at 02:36, Gina P. Banyard wrote:
> On Monday, 11 March 2024 at 16:11, Larry Garfield <larry@garfieldtech.=
com> wrote:
>=20
> >=20
> > Woof. That's my kind of RFC. :-) The extensive background helps a lo=
t, thank you.
> >=20
> > I am generally in favor of this, and have wanted more fine-grained A=
rrayAccess interfaces for a long time.
> >=20
> > Thoughts in no particular order:
> >=20
> > * "Dimension" is clearly based on the existing engine hooks, but as =
a user-space dev, it's a very confusing term. Possibly documentable if t=
here's an obvious logic for it we could present, but something more self=
-evident is probably better.
>=20
> I am open to naming changes, but "dimension" is very much the standard=
 and ubiquitous term for this, see multidimensional arrays, n-dimensiona=
l array, etc.
>=20
> >=20
> > * I am not sure combining get and exists into a single interface is =
right. I'm not certain it's wrong, either, though. What is the argument =
for combining them?
> >=20
> > * Do we have some guidance for what offsetGet() should do when offse=
tExists() is false? I know there isn't really any now, but it seems like=
 the sort of thing to think about here.
>=20
> I will answer both points together.
> The reason that checking an offset exists is combined with being able =
to read it is that it just makes sense to be together.
> If not and only the "read" operation is supported, how do you know tha=
t an offset actually exists before accessing it? You just access it and =
get an Exception that you need to catch?
> It is also required for the null coalesce operator to function properl=
y.
>=20
> What offsetGet() does if the offset doesn't exist is up to the impleme=
ntation, you could return null as a default value or throw an exception.
> The only expectation is that *if* the offset exists, then reading the =
value should be possible.
>=20
> If you can only write to a container, then being able to check somethi=
ng exists is somewhat meaningless.
>=20
>=20
> >=20
> > * You sort of skirt around but don't directly address the impact of =
this change on the long-standing desire to make array functions accept a=
rrayified objects. What if any impact would this have there? Eg, could s=
ome array functions be made to accept array|DimensionRead without breaki=
ng the world?
> >=20
> > * How, if at all, does this relate to iterable? I think it has no im=
pact, but since it's in the same problem space it's worth confirming.
>=20
> The former is actually also more related to iterable, as most array fu=
nctions need to be able to traverse the container to be able to do anyth=
ing meaningful with it.
> Or there would need to be a way to provide a "manifest" of what offset=
s are set for things like array_search or array_flip.
>=20
> >=20
> > * You mention at one point applying shim code ArrayAccess to make it=
 work like the new interfaces. Please expand on that. Do you mean the en=
gine would automatically insert some shims, like how `__toString()` now =
magically implies `implements Stringable`? Or some trait that objects co=
uld use (either a user-space trait or an engine trait) that would provid=
e such shims in an overridable fashion? I don't fully follow here.
> >=20
> > * If I read correctly, an internal object that implements one of the=
 dimension handlers will automagically appear to user-land as having the=
 corresponding interface, much like `__toString()`/`Stringable`. Is that=
 correct? It seemed implied but not fully stated. If so, a brief code ex=
ample would help to make it clear in such a long RFC.
>=20
> Move around a later point to respond to them together.
> Internal objects don't actually magically implement Stringable, this i=
s something internal objects must do themselves.
> Moreover, internals objects can support string casts without implement=
ing __toString(), see the GMP object which is the only example of this i=
n php-src (and I should fix this or if someone else wants an easy PR to =
do feel free).
>=20
> To understand how the shim works, I first need to explain how interfac=
es being implemented in a class work.
>=20
> Internal interfaces can have a special handler called interface_gets_i=
mplemented which gets called during compilation of classes.
> This is the mechanism used by the Throwable and the DateTimeInterface =
interfaces to prevent userland classes from implementing them.
> The ArrayAccess interface has (and all the other Dimension ones actual=
ly have) such a handler, and the "shim" is to set the append, fetch, and=
 fetch-append dimension handlers on the CE to magically support those op=
erations on the class for the time being.
> No methods are created on the class, the new interfaces are not implem=
ented.
> To override the behaviour of append/fetch/fetch-append the relevant ne=
w interface should be implemented.
>=20
> This is conceived as a temporary measure to ease migration for userlan=
d classes that support those operations already.
>=20
>=20
> >=20
> > * Big +1 to removing the magic semi-silent casting when using weird =
key types.
> >=20
> > * I feel like some of the sections could benefit from more short cod=
e examples. Eg, What the heck does fetch-append on a null even look like=
? That would help illustrate why the current behavior is weird, or why s=
ome things need to stay non-obvious because they're used in odd cases. (=
Like how $a[1][2] is a by-ref fetch internally, something most people do=
n't think about.)
> >=20
>=20
> I find having too many examples makes RFCs difficult to read and parse=
, and I prefer to use them sparingly for when they are really needed.
> Just for clarity but $a[1][2] is only a by-ref fetch for write operati=
ons, if it is a read operation those are performed in sequence.
> Fetch-append on null is not really weird, it just appends the given va=
lue (/null if no assignments happens) and provides a reference to it.
> See https://3v4l.org/UPg3P

For what it=E2=80=99s worth, I think having some short one-liner example=
s sprinkled throughout the RFC is a good thing here. I had to constantly=
 scroll back up to remind myself what each operation actually was in cod=
e.=20

There are a lot of familiar concepts, just with new and particular langu=
age; having examples along the way to remind the reader what this new la=
nguage resolves to would help, not hinder.=20

=E2=80=94 Rob
--00d33a1a3fc84430a6ab884adc331813
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Tue, Mar 12, 2024, at 02:36, Gina P. Banyard wrote:<br=
></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Monday, 11=
 March 2024 at 16:11, Larry Garfield &lt;<a href=3D"mailto:larry@garfiel=
dtech.com">larry@garfieldtech.com</a>&gt; wrote:<br></div><div><br></div=
><div>&gt;&nbsp;<br></div><div>&gt; Woof. That's my kind of RFC. :-) The=
 extensive background helps a lot, thank you.<br></div><div>&gt;&nbsp;<b=
r></div><div>&gt; I am generally in favor of this, and have wanted more =
fine-grained ArrayAccess interfaces for a long time.<br></div><div>&gt;&=
nbsp;<br></div><div>&gt; Thoughts in no particular order:<br></div><div>=
&gt;&nbsp;<br></div><div>&gt; * "Dimension" is clearly based on the exis=
ting engine hooks, but as a user-space dev, it's a very confusing term. =
Possibly documentable if there's an obvious logic for it we could presen=
t, but something more self-evident is probably better.<br></div><div><br=
></div><div>I am open to naming changes, but "dimension" is very much th=
e standard and ubiquitous term for this, see multidimensional arrays, n-=
dimensional array, etc.<br></div><div><br></div><div>&gt;&nbsp;<br></div=
><div>&gt; * I am not sure combining get and exists into a single interf=
ace is right. I'm not certain it's wrong, either, though. What is the ar=
gument for combining them?<br></div><div>&gt;&nbsp;<br></div><div>&gt; *=
 Do we have some guidance for what offsetGet() should do when offsetExis=
ts() is false? I know there isn't really any now, but it seems like the =
sort of thing to think about here.<br></div><div><br></div><div>I will a=
nswer both points together.<br></div><div>The reason that checking an of=
fset exists is combined with being able to read it is that it just makes=
 sense to be together.<br></div><div>If not and only the "read" operatio=
n is supported, how do you know that an offset actually exists before ac=
cessing it? You just access it and get an Exception that you need to cat=
ch?<br></div><div>It is also required for the null coalesce operator to =
function properly.<br></div><div><br></div><div>What offsetGet() does if=
 the offset doesn't exist is up to the implementation, you could return =
null as a default value or throw an exception.<br></div><div>The only ex=
pectation is that *if* the offset exists, then reading the value should =
be possible.<br></div><div><br></div><div>If you can only write to a con=
tainer, then being able to check something exists is somewhat meaningles=
s.<br></div><div><br></div><div><br></div><div>&gt;&nbsp;<br></div><div>=
&gt; * You sort of skirt around but don't directly address the impact of=
 this change on the long-standing desire to make array functions accept =
arrayified objects. What if any impact would this have there? Eg, could =
some array functions be made to accept array|DimensionRead without break=
ing the world?<br></div><div>&gt;&nbsp;<br></div><div>&gt; * How, if at =
all, does this relate to iterable? I think it has no impact, but since i=
t's in the same problem space it's worth confirming.<br></div><div><br><=
/div><div>The former is actually also more related to iterable, as most =
array functions need to be able to traverse the container to be able to =
do anything meaningful with it.<br></div><div>Or there would need to be =
a way to provide a "manifest" of what offsets are set for things like ar=
ray_search or array_flip.<br></div><div><br></div><div>&gt;&nbsp;<br></d=
iv><div>&gt; * You mention at one point applying shim code ArrayAccess t=
o make it work like the new interfaces. Please expand on that. Do you me=
an the engine would automatically insert some shims, like how `__toStrin=
g()` now magically implies `implements Stringable`? Or some trait that o=
bjects could use (either a user-space trait or an engine trait) that wou=
ld provide such shims in an overridable fashion? I don't fully follow he=
re.<br></div><div>&gt;&nbsp;<br></div><div>&gt; * If I read correctly, a=
n internal object that implements one of the dimension handlers will aut=
omagically appear to user-land as having the corresponding interface, mu=
ch like `__toString()`/`Stringable`. Is that correct? It seemed implied =
but not fully stated. If so, a brief code example would help to make it =
clear in such a long RFC.<br></div><div><br></div><div>Move around a lat=
er point to respond to them together.<br></div><div>Internal objects don=
't actually magically implement Stringable, this is something internal o=
bjects must do themselves.<br></div><div>Moreover, internals objects can=
 support string casts without implementing __toString(), see the GMP obj=
ect which is the only example of this in php-src (and I should fix this =
or if someone else wants an easy PR to do feel free).<br></div><div><br>=
</div><div>To understand how the shim works, I first need to explain how=
 interfaces being implemented in a class work.<br></div><div><br></div><=
div>Internal interfaces can have a special handler called interface_gets=
_implemented which gets called during compilation of classes.<br></div><=
div>This is the mechanism used by the Throwable and the DateTimeInterfac=
e interfaces to prevent userland classes from implementing them.<br></di=
v><div>The ArrayAccess interface has (and all the other Dimension ones a=
ctually have) such a handler, and the "shim" is to set the append, fetch=
, and fetch-append dimension handlers on the CE to magically support tho=
se operations on the class for the time being.<br></div><div>No methods =
are created on the class, the new interfaces are not implemented.<br></d=
iv><div>To override the behaviour of append/fetch/fetch-append the relev=
ant new interface should be implemented.<br></div><div><br></div><div>Th=
is is conceived as a temporary measure to ease migration for userland cl=
asses that support those operations already.<br></div><div><br></div><di=
v><br></div><div>&gt;&nbsp;<br></div><div>&gt; * Big +1 to removing the =
magic semi-silent casting when using weird key types.<br></div><div>&gt;=
&nbsp;<br></div><div>&gt; * I feel like some of the sections could benef=
it from more short code examples. Eg, What the heck does fetch-append on=
 a null even look like? That would help illustrate why the current behav=
ior is weird, or why some things need to stay non-obvious because they'r=
e used in odd cases. (Like how $a[1][2] is a by-ref fetch internally, so=
mething most people don't think about.)<br></div><div>&gt;&nbsp;<br></di=
v><div><br></div><div>I find having too many examples makes RFCs difficu=
lt to read and parse, and I prefer to use them sparingly for when they a=
re really needed.<br></div><div>Just for clarity but $a[1][2] is only a =
by-ref fetch for write operations, if it is a read operation those are p=
erformed in sequence.<br></div><div>Fetch-append on null is not really w=
eird, it just appends the given value (/null if no assignments happens) =
and provides a reference to it.<br></div><div>See&nbsp;<a href=3D"https:=
//3v4l.org/UPg3P">https://3v4l.org/UPg3P</a><br></div></blockquote><div>=
<br></div><div>For what it=E2=80=99s worth, I think having some short on=
e-liner examples sprinkled throughout the RFC is a good thing here. I ha=
d to constantly scroll back up to remind myself what each operation actu=
ally was in code. <br></div><div><br></div><div>There are a lot of famil=
iar concepts, just with new and particular language; having examples alo=
ng the way to remind the reader what this new language resolves to would=
 help, not hinder.&nbsp;<br></div><div><br></div><div id=3D"sig121229152=
">=E2=80=94 Rob<br></div></body></html>
--00d33a1a3fc84430a6ab884adc331813--