On Wed, May 26, 2021, at 4:31 PM, Sara Golemon wrote:
> On Wed, May 26, 2021 at 2:36 PM Mike Schinkel <firstname.lastname@example.org> wrote:
> > On May 26, 2021, at 2:34 PM, Sara Golemon <email@example.com> 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.
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.)