> On 11 Aug 2022, at 21:42, Larry Garfield <la...@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.crove...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
