Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124342
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <a4d2618a-8df5-4320-bccf-db7406ce5dfc@app.fastmail.com>
In-Reply-To: 
 <CAAKU0umROg0TLOnA0dLpXVOLfV7rOjUhKaYXouTx-dV=CDtR3Q@mail.gmail.com>
References: 
 <mhbeurk_htxbQxzIEs98wQoR8Xczf-L7L8aCAIVhATD7wQiEUJwpAYxYS-llyac0pN761mnQJfpVQcDUoXAgasaWpWylpt6LE-I2oM4zrbk=@gpb.moe>
 <EE-aMte3i-_DTmSrqDgoaRPATmjLUcLt-k31baT8lqqCsrzIy0UsOyKo9rlBs51gWKUK7e7X3VYDuJmxhd6bxOGe52k8ITQgoN0_AE0RnoY=@gpb.moe>
 <CAAKU0umROg0TLOnA0dLpXVOLfV7rOjUhKaYXouTx-dV=CDtR3Q@mail.gmail.com>
Date: Wed, 10 Jul 2024 07:10:33 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets
 and containers
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jul 9, 2024, at 7:52 PM, Levi Morrison wrote:
>> Moreover, I know the traffic on the list has been pretty high, but I do intend to have this RFC up for voting for inclusion in PHP 8.4, and I'm not exactly sure how I am meant to interpret the lack of responses.
>
> I am personally strongly in favor of the direction. As mentioned in
> the PR, my main concern is honestly quite a small one: I think
> `Appendable::append` ought to be renamed. Maybe `Appendable` and
> `FetchAppendable` too.
>
> The reason is that `append` is a common operation on a container type,
> which is likely to want to implement these interfaces. I easily
> identified a few such things with a quick GitHub search:
>  1. 
> https://github.com/pmjones/php-styler/blob/5c7603f420e3a75a5750b3e54cc95dfdbef7d6e2/src/Line.php#L166
>  2. 
> https://github.com/ParvulaCMS/parvula/blob/dcb1876bef70caa14d09e212838a35cb29e23411/core/Models/Config.php#L46
>
> Given that I anticipate these methods to largely be called by
> handlers, and not by names, I think an easy solution is to just name
> this `offsetAppend` to match the other offset operations. For example,
> I don't anticipate code doing:
>
>     $container->append($item);
>
> I expect largely they will do:
>
>     $container[] = $item;
>
> So it doesn't really matter if the name is `append` or `offsetAppend`
> for the main use-case, and thereby we avoid some road bumps on
> adoption. Any SPL containers with `append`, such as ArrayObject, can
> make it an alias of `offsetAppend`, I think?
>
> Anyway, this is a minor thing, and I will vote yes regardless of
> whether it (and maybe the *Appendable interface names) are changed.
> But I do think it would be prudent to change it. It would also match
> the `offset*` convention of the other interfaces.

Based on my research into collections with Derick, I agree that "append" is not a good name to claim for this interface; it would make it incompatible with standard collection method naming.  offsetAppend() would neatly side-step that issue.  +1 to what Levi said.

As to my limited response so far, it's mostly because I read through the proposal in detail a few months ago when it was first informally put forward and liked it then, and it seems there haven't been any serious changes since for me to comment on.  I am very much in favor, though.

--Larry Garfield