> On 11 Aug 2022, at 22:02, Larry Garfield <la...@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 :)
