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

This is only part of a thread. view whole thread
May 26, 2021 05:44 (Hamza Ahmad)
I read about this extension times ago but didn't know whether it had
been public. If Nikita is reading this, I request him to think of
proposing a modified version of this extension bundled with PHP.
In simple words, he can hide the function that registers a class that
serves as a prototype of a built-in type. And, also provide with
scalar methods for string, int, float and arrays. To get handler
registering functionality added to core, there should be a separate
While I read this thread for the first time, I had following suggestions:
1. All array functions should be moved to its scaler object, and the
word "array_" should also be removed.
2. To maintain backward compatibility, all array_* functions will
become method aliases of scaler array.
3. ArrayObject will also exist for the compatibility purpose, and its
methods will also be added to the scaler array.
Thus, array() or [] will return scaler array object, and following
syntax would become valid:
`[1,2,3,4,5,6,7,8,9] -> reverse();`
`array(1 => 'a', 2 => 'b') -> flip();`
If it happens, users will automatically be stopped from passing
non-array values to array functions, and the error will be caught

On 5/26/21, Iván Arias <> wrote:
> Hi all, > > It sounds like scalar objects by Nikita: ><>nikic<>/scalar_objects<> > > Regards, > Iván Arias. > > Get Outlook for Android<> > > ________________________________ > From: Hendra Gunawan> > Sent: Tuesday, May 25, 2021 10:58:46 PM > To: someniatko <> > Cc: Karoly Negyesi <>; Marco Pivetta <>; > Lynn <>; <> > Subject: Re: [PHP-DEV] A little syntactic sugar on array_* function calls? > > Hello. > >> >> ```php >> $array|>map($fn1, ?)|>filter(?, $fn2); >> $array->map($fn1)->filter($fn2); >> ``` >> > > Whitespace removal is not a solution for code length problems. > You might have a new problem if you do it. "|" is very similar > to the lowercase "L" and uppercase "i". > > It's just an extra 3 characters (", ?" or "?, "). For most people, > this is not a problem at all. people tend to write "one statement per line" > rather than "multi statement line". I myself usually write no more than > 3 statements per line if they are less than 120 characters. > > The real problem is there is no consistency for "haystack vs needle" > position. There are RFCs to fix this (along with the naming convention > problem), but none of them are successful. > >> The pipe operator feels like a poor solution while "->" would do >> exactly what people want. > > Not so poor if we > * use "~>" as pipe operator rather than "|>" > * redesign the api under their proper namespace and strictly place > the "haystack" as the first function argument. > > Regards, > Hendra Gunawan. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: > >
May 26, 2021 10:29 (Hossein Baghayi)
On Wed, 26 May 2021 at 10:14, Hamza Ahmad>

> Thus, array() or [] will return scaler array object, >
Hello, This doesn't seem trivial to me. I mean, should array object be passed by value or by reference? Arrays are passed by value by default so far, and objects are be-ref internally. If we are to have array object, will it be exceptional? Or should we change its behaviour going forward? To be clear, array() returns an array right now, which by default is passed by value at the moment. If it was supposed to be changed to an object, (array() to return an object), should it be still passed by value? (an exceptional object) or we should change its behaviour going forward and pass it by-ref? Either way, it may have some quirks associated with it.