Re: A little syntactic sugar on array_* function calls?
| From: | Larry Garfield | Date: | Wed, 26 May 2021 22:07:40 +0000 |
| Subject: | Re: A little syntactic sugar on array_* function calls? | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-114628@lists.php.net to get a copy of this message | ||
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\ˆú
> > FNÐ’ä@g dP` 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