Re: [Concept] Extension methods

> On 11 Aug 2022, at 21:42, Larry Garfield <larry@garfieldtech.com> wrote: > > On Thu, Aug 11, 2022, at 4:03 AM, Alex Wells wrote: > >> Besides, I believe working with existing functions is more of a problem >> than a bonus - because of the naming. You’d have to clutter your code >> with array_map calls, even though it could easily be >> shortened to >> map. > > A couple of trivial higher order functions and you're good to go. I have a sampling of > them here: https://github.com/Crell/fp/blob/master/src/array.php > > (Modulo PHP's inconsistency between internal/user-space functions that force having > separate functions for keyed and unkeyed arrays; any solution is going to have to deal with that > problem.) > >>> On 11 Aug 2022, at 07:36, Paul Crovella <paul.crovella@gmail.com> wrote: >>> >>> This is essentially making -> the pipe operator with >>> extra steps (extension/use >>> extension) and less utility (not working on existing functions.) >> >> Well, pipe operator is another option, but it’s got it’s downsides >> compared to extension methods: >> - it's less versatile: extension methods are required to specify a >> type they’re extending, meaning they are methods, not functions. Hence, >> two different map method extensions can be imported in a >> single file >> (given they’re for different types - say one for >> Collection, the >> other for array), unlike regular functions. I believe >> it’s common >> place to use both Collection::map and >> array::map in a single file, >> but that wouldn’t be possible or would require aliasing >> - it’s uglier: since it just uses functions, to avoid clashes between >> same method names, prefixes would be required > > Flipside: Pipe works on arrays and strings, which this would not. And arrays and strings are > among the most common things to be chained in this way. (Most Collection objects are just alternate > OOPy syntax around array_map and array_filter, at the end of the day.) Pipe also doesn't give > the impression that the method is "part of" the object (it's not), whereas extensions > do, despite being effectively just an alternate syntax for a public function that takes the object > as an argument. > > And functions can be easily namespaced. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Why would this not work on arrays and strings? The intention is the exact opposite: allow extension on (almost) all types allowed in PHP. That includes all scalars, object, iterable, array, mixed, all classes, interfaces & enums. Regarding the impression, I agree. I’m not sure if this is a problem though, as this isn’t a problem in other languages. I’m aware it’s not a correct to compare PHP with other languages, but in this context PHP is facing a question that wasn’t much different for other languages. This is also easily solvable by introducing an extension member access operator - something like ->>. Alternatively, an IDE can just highlight a method as being from an extension.