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

This is only part of a thread. view whole thread
  114623
May 26, 2021 18:34 pollita@php.net (Sara Golemon)
On Tue, May 25, 2021 at 4:20 AM Karoly Negyesi <karoly@negyesi.net> wrote:
> I was wondering whether $array->map($somefunction) would be possible. I am > not a C programmer by any stretch but reading ZEND_VM_HOT_OBJ_HANDLER(112 > it seems to me it should be quite easy (famous last words) to find out if > object is an array and if so then > > 1. prepend the string array_ before the method name > 2. based on a small lookup table move the "object" to the right place -- > either first argument or second. > 3. do a function call instead of a method call. >
While I don't love the specifics of the proposal, I am 100% in favor of allowing arrays to be used in an object-like fashion. 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. In many cases these will be simple trampolines to an existing function, but it gives us self-documenting stubs and room to wiggle out of poor decisions from the 1990s. Such a class would not be instantiable or inheritable, it would just exist as a lightweight ValueObject for performing the method invocations (we can make it internally instantiable using tricks like not calling a private constructor). Then some hand-wavey details about maybe returning objects which have a cast-to-array handler, mumble mumble, devil in the details... waving hands... -Sara
  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