Hello, 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 RFC. 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 earlier. Regards On 5/26/21, IvÃ¡n Arias <firstname.lastname@example.org> wrote:> Hi all, > > It sounds like scalar objects by Nikita: > https://github.com/<https://github.com/nikic/scalar_objects>nikic<https://github.com/nikic/scalar_objects>/scalar_objects<https://github.com/nikic/scalar_objects> > > Regards, > IvÃ¡n Arias. > > Get Outlook for Android<https://aka.ms/AAb9ysg> > > ________________________________ > From: Hendra Gunawan
email@example.com> > Sent: Tuesday, May 25, 2021 10:58:46 PM > To: someniatko <firstname.lastname@example.org> > Cc: Karoly Negyesi <email@example.com>; Marco Pivetta <firstname.lastname@example.org>; > Lynn <email@example.com>; firstname.lastname@example.org <email@example.com> > 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: https://www.php.net/unsub.php > >May 26, 2021 10:29 firstname.lastname@example.org (Hossein Baghayi)On Wed, 26 May 2021 at 10:14, Hamza Ahmad email@example.com> wrote:> 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.