Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122611
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-251-g8332da0bf6-fm-20240305.001-g8332da0b
Precedence: bulk
MIME-Version: 1.0
Message-ID: <afccf689-7b0d-4758-9b11-c532775bd34f@app.fastmail.com>
In-Reply-To: 
 <1MzJ8G_MuG-LJsMSoGDIRBmSODjO4hxPACqMoQYfx83MS-du6sskpNLJ45HnzPYMoUNkXyGiZEUAtFk-uyeGDv_Kwg6Qgtod05pXCQH-8M8=@gpb.moe>
References: 
 <1MzJ8G_MuG-LJsMSoGDIRBmSODjO4hxPACqMoQYfx83MS-du6sskpNLJ45HnzPYMoUNkXyGiZEUAtFk-uyeGDv_Kwg6Qgtod05pXCQH-8M8=@gpb.moe>
Date: Mon, 11 Mar 2024 16:11:16 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Pre-RFC] Improve language coherence for the behaviour of
 offsets and containers
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Mar 11, 2024, at 12:52 PM, Gina P. Banyard wrote:
> Hello internals,
>
> I would like to get some initial feedback on an RFC I've been working=20
> on for the last 5=E2=80=936 months.
> The RFC attempts to explain, and most importantly, improve the=20
> semantics around $container[$offset] as PHP is currently widely=20
> inconsistent.
>
> The RFC is about six thousands words, so I would recommend a cup of=20
> tea/coffee before starting to read it.
>
> The main things which are still in flux is the naming of the new=20
> interfaces and methods, the phrasing of error messages, and the=20
> behaviour around using null as a container.
> Those are generally indicated with a TODO comment.
>
> Of note is that I will also be going on holiday for 3 weeks from the=20
> 19th of March, so ideally most of the feedback would come during that=20
> time frame so that I can finalize the RFC after my holiday.
>
> RFC:=20
> https://github.com/Girgias/php-rfcs/blob/master/container-offset-behav=
iour.md
>
>
> Best regards,
>
> Gina P. Banyard

Woof.  That's my kind of RFC. :-)  The extensive background helps a lot,=
 thank you.

I am generally in favor of this, and have wanted more fine-grained Array=
Access interfaces for a long time.

Thoughts in no particular order:

* "Dimension" is clearly based on the existing engine hooks, but as a us=
er-space dev, it's a very confusing term.  Possibly documentable if ther=
e's an obvious logic for it we could present, but something more self-ev=
ident is probably better.

* I am not sure combining get and exists into a single interface is righ=
t.  I'm not certain it's wrong, either, though.  What is the argument fo=
r combining them?

* Do we have some guidance for what offsetGet() should do when offsetExi=
sts() is false?  I know there isn't really any now, but it seems like th=
e sort of thing to think about here.

* 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 array=
ified objects.  What if any impact would this have there?  Eg, could som=
e array functions be made to accept array|DimensionRead without breaking=
 the world?

* How, if at all, does this relate to iterable?  I think it has no impac=
t, but since it's in the same problem space it's worth confirming.

* You mention at one point applying shim code ArrayAccess to make it wor=
k like the new interfaces.  Please expand on that.  Do you mean the engi=
ne would automatically insert some shims, like how `__toString()` now ma=
gically implies `implements Stringable`?  Or some trait that objects cou=
ld use (either a user-space trait or an engine trait) that would provide=
 such shims in an overridable fashion?  I don't fully follow here.

* Big +1 to removing the magic semi-silent casting when using weird key =
types.

* I feel like some of the sections could benefit from more short code ex=
amples.  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 som=
e things need to stay non-obvious because they're used in odd cases. (Li=
ke how $a[1][2] is a by-ref fetch internally, something most people don'=
t think about.)

* What would the changes to ArrayObject mean for a backing object that u=
ses hooks on some properties?  It says __get/__set would be bypassed.  W=
ould hooks also be bypassed?  (I have no clue what the preferred logic h=
ere is, honestly.  Just thinking aloud and hoping hooks pass so that we =
have to think about this. :-) )

* If I read correctly, an internal object that implements one of the dim=
ension handlers will automagically appear to user-land as having the cor=
responding interface, much like `__toString()`/`Stringable`.  Is that co=
rrect?  It seemed implied but not fully stated.  If so, a brief code exa=
mple would help to make it clear in such a long RFC.

Again, thank you for your work on this, and I hope it passes easily.

--Larry Garfield