Re: A little syntactic sugar on array_* function calls?

> On May 26, 2021, at 2:34 PM, Sara Golemon <pollita@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 <ocramius@gmail.com> wrote: > > On Wed, May 26, 2021 at 1:03 PM Mike Schinkel <mike@newclarity.net > <mailto:mike@newclarity.net>> wrote: > > > > On May 25, 2021, at 6:28 PM, Iván Arias <txigreman@hotmail.com > > <mailto:txigreman@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