Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118410
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
In-Reply-To: <62f48769.250a0220.37387.53b5SMTPIN_ADDED_MISSING@mx.google.com>
Date: Thu, 11 Aug 2022 12:03:11 +0300
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <01D4987C-FD37-4BD2-A1AC-DD10F808F248@gmail.com>
References: <CABigaAWAMfjTh9FBhu-SQRfu9_pgqt5pp7uj4kmNg0QmXbnS-Q@mail.gmail.com>
 <62f48769.250a0220.37387.53b5SMTPIN_ADDED_MISSING@mx.google.com>
To: Paul Crovella <paul.crovella@gmail.com>
Subject: Re: [PHP-DEV] [Concept] Extension methods
From: autaut03@gmail.com (Alex Wells)


> On 11 Aug 2022, at 07:36, Paul Crovella <paul.crovella@gmail.com> =
wrote:
>=20
> This isn't impossible. There's nothing stopping an IDE from seeing =
`$collection->` and suggesting/completing that with `map($collection, ` =
- they just don't right now. Offhand I don't see why this would be more =
difficult for them to implement than support for extension methods. As a =
bonus it'd work with existing functions.

What=E2=80=99s stopping them is that those functions aren=E2=80=99t =
methods. It=E2=80=99d be strange for `$collection->m` to auto-complete =
to `map($collection, `. Even more strange would be the case where =
you=E2=80=99re trying to auto-complete on a big multiline expression.=20

Besides, I believe working with existing functions is more of a problem =
than a bonus - because of the naming. You=E2=80=99d have to clutter your =
code with `array_map` calls, even though it could easily be shortened to =
`map`.


> On 11 Aug 2022, at 07:36, Paul Crovella <paul.crovella@gmail.com> =
wrote:
>=20
> In short every ugly example has a fine, easy-to-read way of writing it =
now in existing code. A useful readability comparison would pit the new =
feature against the best looking version of example code you can come up =
with rather than the worst. Without that you're not really demonstrating =
improvement.

That=E2=80=99s just a concept. I=E2=80=99d love to bring a lot more =
examples in an RFC if there=E2=80=99s more positive than negative =
feedback. Again, I=E2=80=99m more looking for feedback than trying to =
convince someone, but I=E2=80=99ll showcase a couple real comparisons =
for some context:

Compere these (copied from real world project/public composer packages):
```php
$className =3D Str::studly(implode('_', array_slice(explode('_', =
$file->getName()), 4)));
// vs
$className =3D =
$file->getName()->explode(=E2=80=98_=E2=80=99)->slice(4)->implode(=E2=80=98=
_=E2=80=99)->studly();

array_map(fn (string $item) =3D> trim(mb_strtolower(strip_tags($item))), =
trans('contacts::tenants.gender_types=E2=80=99));
// vs
trans('contacts::tenants.gender_types=E2=80=99)->map(fn (string $item) =
=3D> $item->stripTags()->lower()->trim());

array_merge($oldResponse, array_map(fn (Response $v) =3D> =
Arr::except($v->toArray(), 'message'), $newResponse))
// vs
$oldResponse->merge($newResponse->map(fn (Response $v) =3D> =
$v->toArray()->except(=E2=80=98message')))
```

All these changes lead to a lower cognitive load, because:
 - you aren=E2=80=99t dealing with lots of nested parenthesis
 - you aren=E2=80=99t trying to read expressions =E2=80=9Cinside-out=E2=80=
=9D
 - you aren=E2=80=99t messing with not-so-useful prefixes like `Arr::`, =
`array`, `str`

You could argue the problem is that all of these are single-liners, so =
here are the same examples, but multiline formatted:

```php
$className =3D Str::studly(
    implode(
        '_=E2=80=99,=20
        array_slice(
            explode(
                '_=E2=80=99,
                $file->getName()
            ),=20
            4
        )
    )
);
// vs
$className =3D $file->getName()
    ->explode(=E2=80=98_=E2=80=99)
    ->slice(4)
    ->implode(=E2=80=98_=E2=80=99)
    ->studly();

array_map(
    fn (string $item) =3D> trim(
        mb_strtolower(
            strip_tags($item)
        )
    ),
    trans('contacts::tenants.gender_types=E2=80=99)
);
// vs
trans('contacts::tenants.gender_types=E2=80=99)->map(
    fn (string $item) =3D> $item
        ->stripTags()
        ->lower()
        ->trim()
);

array_merge(
    $oldResponse,=20
    array_map(
        fn (Response $v) =3D> Arr::except($v->toArray(), 'message'),=20
        $newResponse
    )
)
// vs
$oldResponse->merge(
    $newResponse->map(
        fn (Response $v) =3D> $v
            ->toArray()
            ->except(=E2=80=98message=E2=80=99)
    )
)
```

I believe the difference is quite obvious.=20

Not an argument, but one more thing to consider: if current state of =
things in PHP was =E2=80=9Cgood enough=E2=80=9D, why do library authors =
come up with those magic method trait solutions, and why we=E2=80=99re =
seeing types like `Collection` being used instead of `array` and =
`Stringable` (laravel) instead of `string`, when you could instead just =
introduce a bunch of functions?


> On 11 Aug 2022, at 07:36, Paul Crovella <paul.crovella@gmail.com> =
wrote:
>=20
> An extension method would shift a single argument from inside =
parentheses to the left of the function name. It just moves it. I don't =
see any impact here.

It doesn=E2=80=99t move it, it removes it. You=E2=80=99re technically =
not passing that value as an argument anymore anywhere in your code, =
your value becomes the implicit expression you=E2=80=99re working with. =
That becomes even more obvious when multiple method calls are chained =
and don=E2=80=99t need to pass it into every function call.


> On 11 Aug 2022, at 07:36, Paul Crovella <paul.crovella@gmail.com> =
wrote:
>=20
> 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=E2=80=99s got it=E2=80=99s =
downsides compared to extension methods:
 - it's less versatile: extension methods are required to specify a type =
they=E2=80=99re extending, meaning they are methods, not functions. =
Hence, two different `map` method extensions can be imported in a single =
file (given they=E2=80=99re for different types - say one for =
`Collection`, the other for `array`), unlike regular functions. I =
believe it=E2=80=99s common place to use both `Collection::map` and =
`array::map` in a single file, but that wouldn=E2=80=99t be possible or =
would require aliasing
 - it=E2=80=99s uglier: since it just uses functions, to avoid clashes =
between same method names, prefixes would be required