> On May 26, 2021, at 2:34 PM, Sara Golemon <poll...@php.net> wrote: > > What I don't like about the specific proposal is that it's just a little > too magic in its function selection and argument mapping. There's also the > fact that it doesn't leave room to improve specifics about the > implementations of the methods. I'd much rather seen an `Array` class > defined with specific methods declared on it.
Wouldn't an `Array` class necessarily result in array-incompatible pass-by-reference semantics, which is one of the same issues with userland using ArrayObject as an array replacement? > On May 26, 2021, at 7:51 AM, Marco Pivetta <ocram...@gmail.com> wrote: > > On Wed, May 26, 2021 at 1:03 PM Mike Schinkel <m...@newclarity.net > <mailto:m...@newclarity.net>> wrote: > > > > On May 25, 2021, at 6:28 PM, Iván Arias <txigre...@hotmail.com > > <mailto:txigre...@hotmail.com>> wrote: > > > > Hi all, > > > > It sounds like scalar objects by Nikita: > > https://github.com/nikic/scalar_objects > > <https://github.com/nikic/scalar_objects> > > Yes, but Nikita wrote this note about technical limitations at the bottom of > the repo README: > > 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). > > Sounds like a big **advantage**? Yes, it is a big advantage. Except for when it is not. -Mike
