Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

This is only part of a thread. view whole thread
  114625
May 26, 2021 19:35 mike@newclarity.net (Mike Schinkel)
> 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
  114627
May 26, 2021 21:31 pollita@php.net (Sara Golemon)
On Wed, May 26, 2021 at 2:36 PM Mike Schinkel <mike@newclarity.net> wrote:

> 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? > > It would if the Array objects got returned. I'm instead picturing an
instance that magically comes into being solely for the duration of the method call. Once the method returns, the object vanishes. -Sara
  114628
May 26, 2021 22:07 larry@garfieldtech.com ("Larry Garfield")
On Wed, May 26, 2021, at 4:31 PM, Sara Golemon wrote:
> On Wed, May 26, 2021 at 2:36 PM Mike Schinkel <mike@newclarity.net> wrote: > > > 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? > > > > > It would if the Array objects got returned. I'm instead picturing an > instance that magically comes into being solely for the duration of the > method call. Once the method returns, the object vanishes. > > -Sara
It sounds like you're describing something more akin to "extensions" in C#, or the way trait impls work in Rust, or the way methods get defined in Go. (All of which would be quite neat, but I don't know how they'd play nicely in PHP.) --Larry Garfield