Re: [RFC] Improve language coherence for the behaviour of offsets and containers

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