Re: [Concept] Extension methods

> On 11 Aug 2022, at 22:02, Larry Garfield <larry@garfieldtech.com> wrote: > > On Thu, Aug 11, 2022, at 1:59 PM, Alex Wells wrote: > >>>> 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. > > How feasible is that to implement? > >> 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. > > Numerous languages also included a pipe operator to handle this use case, so... ¯\_(ツ)_/¯ > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > <https://www.php.net/unsub.php> Well.. I think it’s the rest of the feature that is hard. Checking for types should be relatively trivial, as one could use the same logic for extension methods as is used when checking if an argument can be passed into a typed function parameter, but with strict_types=1. So for classes, enums & interfaces it’s instanceof; scalars and array - an exact type match with an exception of int value for float type; iterable/object/mixed also checked as a function parameter. It’s likely I’m missing some edge cases though :)