[Concept] Extension methods

3 years ago by Alex Wells — view source — reply

unread

Hey internals.

The idea is to introduce extension methods, similar to those in Kotlin, C#,
Dart. For those unfamiliar, those are just regular functions with fancy
syntax. However, I think having those will not only improve readability,
but also cover some of the previously requested features.

Say you have a class Collection and you want to add a new method
map(callable $callable): Collection. The first instinct is to go into
that file and add the method, this will work. But what if class Collection is defined in a vendor package? You could define a regular
function like this: map(Collection $collection, callable $callable): Collection, then import it whenever you need to use that.

This solution works, but in practice is rarely used. The reasons are:

there's no IDE completion: $collection-> <- here I want IDE to
auto-complete the map method somehow, but since it's a function this is
impossible
it's ugly looking and hard to read:
getPromotions(mostExpensiveItem(getShoppingList(getCurrentUser(), 'wishlist'), ['exclude' => 'onSale']), $holiday);
it's easy to mess up the order of arguments

The pipe operator RFC [1] was trying to solve that but got rejected.

Major libraries/frameworks like Laravel [2] and Carbon [3] use a solution
with __call that allows users to define custom methods on their classes:
Carbon::mixin('toMyTimeFormat', fn () => $this->format('MM YYYY DD'));

Again, this solution:

doesn't offer IDE completion and doesn't offer IDE navigation
harder to understand
doesn't work with interfaces, traits, enums or primitives

Other languages (Kotlin [4], C# [5], Dart [6]) I'm aware of solve this
problem with extension methods. All of them use slightly different syntax,
but the main idea is:

you define an extension method the same way you define a function, except
you specify which type you're extending
you can use any type that a function can accept. This includes
primitives, classes, interfaces, traits and enums
the type you're extending is implicitly bound to $this
you only have access to the public scope - you can't access
private/protected members
you have to import those the same way you import functions. You can't
define extensions globally

In PHP this could look like this:

// Illuminate/Collection.php
namespace Illuminate;
class Collection {}

// App/CollectionExtension.php
namespace App;
use Illuminate\Collection;

extension CollectionExtension on Collection {
    function map(callable $callable): Collection {
        return new Collection(array_map($callable, $this->items));
    }
}

// App/Business/Logic.php
namespace App\Business;
use extension App\CollectionExtension::map;

(new Collection(1, 2, 3))
    ->map(fn ($value) => $value + 1)
    ->map(fn ($value) => $value * 2);

The way this should work is PHP first checks whether Collection has map
method. If one's missing, it gets all used extensions that match that
method name, autoloads them (the same way other class-likes are loaded) and
checks whether current type Collection matches the type specified in the
extension. If so, calls the method, otherwise attempts to call __call.

This same concept eliminates the need for scalar objects or scalar
extension methods [7].

I'm guessing there will be problems with optimization and OPCache.

What are your thoughts?

References:

3 years ago by Levi Morrison via internals — view source — reply

unread

What are your thoughts?

It's a fantastic feature that I've used in Rust, although there are
some differences. First, it doesn't work for regular methods -- they
have to be part of a trait. Secondly, in general a trait can only be
implemented for a given type if it is in the package which defines
that type, or in the package which defines the trait. Third, the trait
must be in scope. These rules help people understand where the methods
are coming from, which is particularly helpful for large code bases or
teams.

PHP doesn't really have tools for these kinds of restrictions, but I
think it's necessary. You'd need some way to manage where extension
methods are loaded, how they are found, and without pessimizing
performance of method calls in general just because this feature
exists.

3 years ago by Deleu — view source — reply

unread

On Wed, Aug 10, 2022 at 5:16 PM Levi Morrison via internals <
internals@lists.php.net> wrote:

What are your thoughts?

It's a fantastic feature that I've used in Rust, although there are
some differences. First, it doesn't work for regular methods -- they
have to be part of a trait. Secondly, in general a trait can only be
implemented for a given type if it is in the package which defines
that type, or in the package which defines the trait. Third, the trait
must be in scope. These rules help people understand where the methods
are coming from, which is particularly helpful for large code bases or
teams.

PHP doesn't really have tools for these kinds of restrictions, but I
think it's necessary. You'd need some way to manage where extension
methods are loaded, how they are found, and without pessimizing
performance of method calls in general just because this feature
exists.

--

To unsubscribe, visit: https://www.php.net/unsub.php

As I was thinking about how this feature would be cool, I was also worried
about how big of a mess it could become, given the lack of restrictions you
pointed out here. However, knowing how PHP works, I wonder if the following
could be made possible:

// Vendor File
namespace Illuminate\Support;

class Collection {}

// Extension File
namespace App\Whatever;

extension LaravelCollection on Collection {}

// Usage File
namespace App\Business;

use App\Whatever\Laravelcollection;

$collection = (new Collection())->extensionMethodAvailableHere();

The goal here is to
1- Disallow use Class; use ExtensionClass simultaneously (conflicting
symbols on compile-time?)
2- Bind the Base-class Symbol through the ExtensionClass symbol
3- Disallow two extensions to compete with each other
4- The user would always know that a symbol has a method either via 1-level
extension or from the original class directly - it doesn't come from
unknown places

I feel like this would be powerful enough to solve a lot of usability on
PHP OOP while not being crazy enough to create a nightmare on codebases and
the internals of the PHP Engine. Does this make sense?

--
Marco Deleu

3 years ago by Alex Wells — view source — reply

unread

I believe disallowing multiple extensions on one type defeats one of
the purposes of the feature - extending from outside. Let's say you have a
vendor package for manipulating strings which defines an extension on
string type. It works, but then you need one more custom extensions -
some kind of replaceLastRegex method. You define it in your own
extension, but then you're either missing the vendor package methods or
your own extensions. This might even make people avoid extensions, because
there would be no way to use both extensions, hence making them extract
those into functions.

I think that if the goal is to avoid the confusion and/or mess, we could
force specifying the when using the extension. It would then be crystal
clear where the method is coming from and also it'd be trivial to check
whether method names are conflicting between extensions. The syntax is just
a demonstration: use extension App\Whatever\CollectionExtension as Illuminate\Collection::map;

On Wed, Aug 10, 2022 at 5:16 PM Levi Morrison via internals <
internals@lists.php.net> wrote:

What are your thoughts?

It's a fantastic feature that I've used in Rust, although there are
some differences. First, it doesn't work for regular methods -- they
have to be part of a trait. Secondly, in general a trait can only be
implemented for a given type if it is in the package which defines
that type, or in the package which defines the trait. Third, the trait
must be in scope. These rules help people understand where the methods
are coming from, which is particularly helpful for large code bases or
teams.

PHP doesn't really have tools for these kinds of restrictions, but I
think it's necessary. You'd need some way to manage where extension
methods are loaded, how they are found, and without pessimizing
performance of method calls in general just because this feature
exists.

--

To unsubscribe, visit: https://www.php.net/unsub.php

As I was thinking about how this feature would be cool, I was also worried
about how big of a mess it could become, given the lack of restrictions you
pointed out here. However, knowing how PHP works, I wonder if the following
could be made possible:
// Vendor File
namespace Illuminate\Support;

class Collection {}

// Extension File
namespace App\Whatever;

extension LaravelCollection on Collection {}

// Usage File
namespace App\Business;

use App\Whatever\Laravelcollection;

$collection = (new Collection())->extensionMethodAvailableHere();
The goal here is to
1- Disallow use Class; use ExtensionClass simultaneously (conflicting
symbols on compile-time?)
2- Bind the Base-class Symbol through the ExtensionClass symbol
3- Disallow two extensions to compete with each other
4- The user would always know that a symbol has a method either via
1-level extension or from the original class directly - it doesn't come
from unknown places

I feel like this would be powerful enough to solve a lot of usability on
PHP OOP while not being crazy enough to create a nightmare on codebases and
the internals of the PHP Engine. Does this make sense?

--
Marco Deleu

3 years ago by Ben Ramsey — view source — reply

unread

The idea is to introduce extension methods, similar to those in Kotlin, C#,
Dart. For those unfamiliar, those are just regular functions with fancy
syntax. However, I think having those will not only improve readability,
but also cover some of the previously requested features.

Other languages (Kotlin [4], C# [5], Dart [6]) I'm aware of solve this
problem with extension methods. All of them use slightly different syntax,
but the main idea is:

you define an extension method the same way you define a function, except
you specify which type you're extending

you can use any type that a function can accept. This includes
primitives, classes, interfaces, traits and enums

the type you're extending is implicitly bound to $this

you only have access to the public scope - you can't access
private/protected members

you have to import those the same way you import functions. You can't
define extensions globally

I believe this is also called "monkey patching" in some places, and
Ruby, Python, and JavaScript all offer some form of object extension
similar to this.

There is also the PHP runkit extension that provides some of the
functionality you've described: https://www.php.net/runkit7

--
Cheers,
Ben

3 years ago by Paul Crovella — view source — reply

unread

This solution works, but in practice is rarely used. The reasons are:

there's no IDE completion: $collection-> <- here I want IDE to
auto-complete the map method somehow, but since it's a function this is
impossible

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.

it's ugly looking and hard to read:
getPromotions(mostExpensiveItem(getShoppingList(getCurrentUser(), 'wishlist'), ['exclude' => 'onSale']), $holiday);

It's easy to write ugly looking code using any particular syntax. It's
unconvincing to do so. Instead of rehashing it all here I'd suggest
looking back at examples and counter-examples of exactly this sort of
thing in past pipe operator discussions.

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.

The most an ugly example has done for a proposal is generate noise.

it's easy to mess up the order of arguments

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.

The pipe operator RFC [1] was trying to solve that but got rejected.

This is essentially making -> the pipe operator with extra steps
(extension/use extension) and less utility (not working on existing
functions.)

Considering all the conflict resolution stuff would have to be done
anyway you may as well drop the extra steps and explore -> as a pipe
operator directly. Only add in extension/use extension if there's a
blocker they solve - i.e. when they provide real value.

3 years ago by Alex Wells — view source — reply

unread

Sorry, replying to all this time :)

I've missed to pinpoint an important fact: extensions don't add methods to
types per-say, rather they allow using them when imported. Extension's
methods would never be called if the extension isn't imported, which is
different from monkey-patching and runkit, where two parties could attempt
to define the same method twice and end up with only one of them left in
the runtime. This also means that it's perfectly fine for two extensions on
the same type and with the same method names to co-exist and be used
independently. Of course, unless you attempt to import both of them in a
scope of one file.

The idea is to introduce extension methods, similar to those in Kotlin,
C#,
Dart. For those unfamiliar, those are just regular functions with fancy
syntax. However, I think having those will not only improve readability,
but also cover some of the previously requested features.

Other languages (Kotlin [4], C# [5], Dart [6]) I'm aware of solve this
problem with extension methods. All of them use slightly different
syntax,
but the main idea is:

you define an extension method the same way you define a function,
except
you specify which type you're extending

you can use any type that a function can accept. This includes
primitives, classes, interfaces, traits and enums

the type you're extending is implicitly bound to $this

you only have access to the public scope - you can't access
private/protected members

you have to import those the same way you import functions. You can't
define extensions globally

I believe this is also called "monkey patching" in some places, and
Ruby, Python, and JavaScript all offer some form of object extension
similar to this.

There is also the PHP runkit extension that provides some of the
functionality you've described: https://www.php.net/runkit7

--
Cheers,
Ben

3 years ago by Rowan Tommins — view source — reply

unread

I believe this is also called "monkey patching" in some places, and
Ruby, Python, and JavaScript all offer some form of object extension
similar to this.

There is also the PHP runkit extension that provides some of the
functionality you've described: https://www.php.net/runkit7

Monkey-patching generally refers to the ability to completely "re-open" a
class, and implement additional behaviour (or even change existing
behaviour) with the same privileges as the original definition.

Extension methods are a much more constrained feature - they don't break
the class's encapsulation, only provide an extra syntax for operations that
would already be legal. In C#, for instance, calling
"foo.someExtensionMethod(bar)" is just syntactic sugar for the static
method call "SomeClass.someExtensionMethod(foo, bar)", and cannot hide or
over-ride a real method with the same name.

The challenge in PHP is that so little is resolved at compile-time.
Adapting the example from the first post:

namespace App\Business;
use extension App\CollectionExtension::map on Collection;

function foo($x) {
$x
->map(fn ($value) => $value + 1)
->map(fn ($value) => $value * 2);
}

PHP doesn't know until run-time:

whether App\CollectionExtension actually exists (the compiler does not
have access to an autoloader)
whether it defines a "map" method, and applies to type Collection, even
if the user has claimed that in the "use" statement
what type $x will be; even with a type constraint of "Collection $x", it
might be a sub-type, changing the answer to the following question
whether that class already contains a "map" method, or an __call handler

I think we would have to implement it as a final fall-back for missing
methods, between __call and throwing an error:

at compile-time, build a list of in-scope extensions methods; note that
these would just be strings at this point, not loaded code
just before throwing a "method not found" error, loop over the list,
autoloading each entry if necessary; possibly at this point, errors would
be raised for naming conflicts and other violations
check each in-scope extension method in turn for an "instanceof" match
against the current object
if one matches, despatch the call
if none matches, throw an error as normal

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Alex Wells — view source — reply

unread

Thanks for explaining it better than I did.

Regarding the implementation, that was roughly what I was thinking.

But can't we put extension methods second, after real methods but before
__call? As far as I understand, the reason to put it after __call is to
avoid a performance penalty on __call calls, but this would mean extension
methods are not possible for classes that implement __call. Not a huge
deal, but a thing to consider.

On Wed, Aug 10, 2022 at 8:32 PM Rowan Tommins rowan.collins@gmail.com
wrote:

I believe this is also called "monkey patching" in some places, and
Ruby, Python, and JavaScript all offer some form of object extension
similar to this.

There is also the PHP runkit extension that provides some of the
functionality you've described: https://www.php.net/runkit7

Monkey-patching generally refers to the ability to completely "re-open" a
class, and implement additional behaviour (or even change existing
behaviour) with the same privileges as the original definition.

Extension methods are a much more constrained feature - they don't break
the class's encapsulation, only provide an extra syntax for operations that
would already be legal. In C#, for instance, calling
"foo.someExtensionMethod(bar)" is just syntactic sugar for the static
method call "SomeClass.someExtensionMethod(foo, bar)", and cannot hide or
over-ride a real method with the same name.

The challenge in PHP is that so little is resolved at compile-time.
Adapting the example from the first post:

namespace App\Business;
use extension App\CollectionExtension::map on Collection;

function foo($x) {
$x
->map(fn ($value) => $value + 1)
->map(fn ($value) => $value * 2);
}

PHP doesn't know until run-time:

whether App\CollectionExtension actually exists (the compiler does not
have access to an autoloader)

whether it defines a "map" method, and applies to type Collection, even
if the user has claimed that in the "use" statement

what type $x will be; even with a type constraint of "Collection $x", it
might be a sub-type, changing the answer to the following question

whether that class already contains a "map" method, or an __call handler

I think we would have to implement it as a final fall-back for missing
methods, between __call and throwing an error:

at compile-time, build a list of in-scope extensions methods; note that
these would just be strings at this point, not loaded code

just before throwing a "method not found" error, loop over the list,
autoloading each entry if necessary; possibly at this point, errors would
be raised for naming conflicts and other violations

check each in-scope extension method in turn for an "instanceof" match
against the current object

if one matches, despatch the call

if none matches, throw an error as normal

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Rowan Tommins — view source — reply

unread

Thanks for explaining it better than I did.

Regarding the implementation, that was roughly what I was thinking.

But can't we put extension methods second, after real methods but before
__call? As far as I understand, the reason to put it after __call is to
avoid a performance penalty on __call calls, but this would mean extension
methods are not possible for classes that implement __call. Not a huge
deal, but a thing to consider.

To be honest, I put them in that order more for "purity" reasons: if they come before __call, they can change the existing behaviour of the class, by defining an extension method with the same name as a "virtual" method implemented with __call. That then becomes a very different feature.

If there was a way for __call to signal "no implementation for this method name", you could look for extension methods if that was returned; but at the moment, a class implementing __call is assumed to reserve all method names.

I suppose a related question is whether __call itself could be implemented by an extension method. I would suggest no, to keep things simpler.

(Aside: Reminder that convention on this list is to "bottom-post": quote the part of message you're replying to, then add your text below.)

--
Rowan Tommins
[IMSoP]

3 years ago by Alex Wells — view source — reply

unread

a class implementing __call is assumed to reserve all method names.

This does make sense. Either an extension has precedence over class methods or it does not; having extension methods in the middle of statically defined methods and __call would likely do more harm than good.

I suppose a related question is whether __call itself could be implemented by an extension method. I would suggest no, to keep things simpler.

I agree. I can’t think of a magic method that should be allowed to be defined as an extension method. None of them make sense.

(Aside: Reminder that convention on this list is to "bottom-post": quote the part of message you're replying to, then add your text below.)

Apologies. Still getting used to emails.

3 years ago by Deleu — view source — reply

unread

On Wed, Aug 10, 2022, 11:30 PM Rowan Tommins rowan.collins@gmail.com
wrote:

To be honest, I put them in that order more for "purity" reasons: if they
come before __call, they can change the existing behaviour of the class, by
defining an extension method with the same name as a "virtual" method
implemented with __call. That then becomes a very different feature.

I would argue in favor of extension having precedence over __call because

classes with __call wouldn't be able to be extended and 2) extensions
could actually "fix" the ~ab~use of some use of __call. I suppose this
would allow me to write an Extension that mimics the exact behavior of
__call and actually avoid __call from being hit while still keeping the
same behavior of the class.

3 years ago by Larry Garfield — view source — reply

unread

On Wed, Aug 10, 2022, 11:30 PM Rowan Tommins rowan.collins@gmail.com
wrote:

To be honest, I put them in that order more for "purity" reasons: if they
come before __call, they can change the existing behaviour of the class, by
defining an extension method with the same name as a "virtual" method
implemented with __call. That then becomes a very different feature.

I would argue in favor of extension having precedence over __call because

classes with __call wouldn't be able to be extended and 2) extensions
could actually "fix" the ~ab~use of some use of __call. I suppose this
would allow me to write an Extension that mimics the exact behavior of
__call and actually avoid __call from being hit while still keeping the
same behavior of the class.

Possibly very dumb idea, but I'll throw it out anyway:

Would it be OK if extension methods came before normal methods? Would that allow a compile time translation of this:

use extension Foo:bar;

$collection->bar($b);

to this:

Foo::bar($collection, $b);

Since the extension would only have public access anyway (modulo messing around with rebinding and reflection, of course), it's logically equivalent to just a static method like that. That could allow the existing autoload logic to work (if extensions compile into just classes), and no runtime overhead because it's "Just" a static method call; if it's missing, oh well, it just fails like a static method call.

A side effect of that is indeed that you could override an object's method externally, in effect, at the loss of internal access. I... could probably make a solid argument for that being very good or very bad, depending on my mood.

(I'm at the moment lukewarm on the idea overall, and I still believe pipes are the superior solution, but if we do it then it should be done well.)

--Larry Garfield

3 years ago by Rowan Tommins — view source — reply

unread

Would it be OK if extension methods camebefore normal methods?

It would certainly be possible, and seems more logical than allowing
extensions to over-ride __call but not anything else. It does lead to a
very different feature, though: it means that you can take a fully
working unit of code, add a "use extension" line at the top, and change
the behaviour of that code.

I haven't looked in detail at how other languages implement them, but my
impression is that such a behaviour change would be something other than
an "extension method" as normally understood.

Would that allow a compile time translation of this:

use extension Foo:bar;

$collection->bar($b);

to this:

Foo::bar($collection, $b);

Unfortunately not, because the compiler doesn't know anything about the
type of $collection, so doesn't know whether to apply the extension. The
process would look something like this:

at compile-time, build a list of in-scope extension methods
before every method call, loop over the list, autoloading each entry
if necessary
check each in-scope extension method in turn for an "instanceof"
match against the current object
if one matches, despatch the call
if none matches, continue with the method call as normal

The lookup could be optimized in various ways (particularly if the user
has to list every method they want to be in scope), but as far as I can
see, giving extension methods higher priority will always be worse for
performance, because the lookups will happen more often. Giving them
lowest priority, just above throwing an error, is effectively free,
unless you're doing something very weird and care about the performance
of errors.

Regards,

--
Rowan Tommins
[IMSoP]

3 years ago by Larry Garfield — view source — reply

unread

Would it be OK if extension methods camebefore normal methods?

It would certainly be possible, and seems more logical than allowing
extensions to over-ride __call but not anything else. It does lead to a
very different feature, though: it means that you can take a fully
working unit of code, add a "use extension" line at the top, and change
the behaviour of that code.

I haven't looked in detail at how other languages implement them, but my
impression is that such a behaviour change would be something other than
an "extension method" as normally understood.

Would that allow a compile time translation of this:

use extension Foo:bar;

$collection->bar($b);

to this:

Foo::bar($collection, $b);

Unfortunately not, because the compiler doesn't know anything about the
type of $collection, so doesn't know whether to apply the extension. The
process would look something like this:

Ah, good point. I keep forgetting that even though well-written code has pretty sold type information, it's not quite enough to be able to do anything useful at compile time, generally. Poopy. If that makes the performance even worse on every method call then it's definitely not worth considering.

--Larry Garfield

3 years ago by michal.brzuchalski@gmail.com — view source — reply

unread

Hi Rowan,

śr., 10 sie 2022 o 19:32 Rowan Tommins rowan.collins@gmail.com napisał(a):

I believe this is also called "monkey patching" in some places, and
Ruby, Python, and JavaScript all offer some form of object extension
similar to this.

There is also the PHP runkit extension that provides some of the
functionality you've described: https://www.php.net/runkit7

Monkey-patching generally refers to the ability to completely "re-open" a
class, and implement additional behaviour (or even change existing
behaviour) with the same privileges as the original definition.

Extension methods are a much more constrained feature - they don't break
the class's encapsulation, only provide an extra syntax for operations that
would already be legal. In C#, for instance, calling
"foo.someExtensionMethod(bar)" is just syntactic sugar for the static
method call "SomeClass.someExtensionMethod(foo, bar)", and cannot hide or
over-ride a real method with the same name.

The challenge in PHP is that so little is resolved at compile-time.
Adapting the example from the first post:

namespace App\Business;
use extension App\CollectionExtension::map on Collection;

function foo($x) {
$x
->map(fn ($value) => $value + 1)
->map(fn ($value) => $value * 2);
}

This is close to what I was thinking, there might be even more extended map
of methods and aliases similar to parentheses block known from traits use.
But what is my biggest concern is the amount of changes in opcache cuz this
proposal would require storing each Collection class entry patched by a
given extension for each class name - but these things are not really
runtime at all - meaning we may end up with a blocker because namespaces
are not a real thing in PHP.

Cheers,
Michał Marcin Brzuchalski

3 years ago by Alex Wells — view source — reply

unread

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’s stopping them is that those functions aren’t methods. It’d be strange for $collection->m to auto-complete to map($collection, . Even more strange would be the case where you’re trying to auto-complete on a big multiline expression.

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.

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’s just a concept. I’d love to bring a lot more examples in an RFC if there’s more positive than negative feedback. Again, I’m more looking for feedback than trying to convince someone, but I’ll showcase a couple real comparisons for some context:

Compere these (copied from real world project/public composer packages):

$className = Str::studly(implode('_', array_slice(explode('_', $file->getName()), 4)));
// vs
$className = $file->getName()->explode(‘_’)->slice(4)->implode(‘_’)->studly();

array_map(fn (string $item) => trim(mb_strtolower(strip_tags($item))), trans('contacts::tenants.gender_types’));
// vs
trans('contacts::tenants.gender_types’)->map(fn (string $item) => $item->stripTags()->lower()->trim());

array_merge($oldResponse, array_map(fn (Response $v) => Arr::except($v->toArray(), 'message'), $newResponse))
// vs
$oldResponse->merge($newResponse->map(fn (Response $v) => $v->toArray()->except(‘message')))

All these changes lead to a lower cognitive load, because:

you aren’t dealing with lots of nested parenthesis
you aren’t trying to read expressions “inside-out”
you aren’t 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:

$className = Str::studly(
    implode(
        '_’, 
        array_slice(
            explode(
                '_’,
                $file->getName()
            ), 
            4
        )
    )
);
// vs
$className = $file->getName()
    ->explode(‘_’)
    ->slice(4)
    ->implode(‘_’)
    ->studly();

array_map(
    fn (string $item) => trim(
        mb_strtolower(
            strip_tags($item)
        )
    ),
    trans('contacts::tenants.gender_types’)
);
// vs
trans('contacts::tenants.gender_types’)->map(
    fn (string $item) => $item
        ->stripTags()
        ->lower()
        ->trim()
);

array_merge(
    $oldResponse, 
    array_map(
        fn (Response $v) => Arr::except($v->toArray(), 'message'), 
        $newResponse
    )
)
// vs
$oldResponse->merge(
    $newResponse->map(
        fn (Response $v) => $v
            ->toArray()
            ->except(‘message’)
    )
)

I believe the difference is quite obvious.

Not an argument, but one more thing to consider: if current state of things in PHP was “good enough”, why do library authors come up with those magic method trait solutions, and why we’re 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?

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’t move it, it removes it. You’re technically not passing that value as an argument anymore anywhere in your code, your value becomes the implicit expression you’re working with. That becomes even more obvious when multiple method calls are chained and don’t need to pass it into every function call.

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

3 years ago by Christian Schneider — view source — reply

unread

Am 11.08.2022 um 11:03 schrieb Alex Wells autaut03@gmail.com:

That’s just a concept. I’d love to bring a lot more examples in an RFC if there’s more positive than negative feedback. Again, I’m more looking for feedback than trying to convince someone, but I’ll showcase a couple real comparisons for some context:

Compere these (copied from real world project/public composer packages):
$className = Str::studly(implode('_', array_slice(explode('_', $file->getName()), 4)));
// vs
$className = $file->getName()->explode(‘_’)->slice(4)->implode(‘_’)->studly();

This reminds me of the proposed (but declined) pipe operator
https://wiki.php.net/rfc/pipe-operator-v2
but I'd still prefer to have it as a generic operator instead of using a pseudo-OO approach for this.
I say pseudo-OO because not everything in PHP is an object plus using the -> syntax IMHO muddies the water.

Regards,

Chris

3 years ago by Alex Wells — view source — reply

unread

Am 11.08.2022 um 11:03 schrieb Alex Wells autaut03@gmail.com:
That’s just a concept. I’d love to bring a lot more examples in an RFC if there’s more positive than negative feedback. Again, I’m more looking for feedback than trying to convince someone, but I’ll showcase a couple real comparisons for some context:

Compere these (copied from real world project/public composer packages):
$className = Str::studly(implode('_', array_slice(explode('_', $file->getName()), 4)));
// vs
$className = $file->getName()->explode(‘_’)->slice(4)->implode(‘_’)->studly();
This reminds me of the proposed (but declined) pipe operator
https://wiki.php.net/rfc/pipe-operator-v2
but I'd still prefer to have it as a generic operator instead of using a pseudo-OO approach for this.
I say pseudo-OO because not everything in PHP is an object plus using the -> syntax IMHO muddies the water.

Regards,

Chris

--

To unsubscribe, visit: https://www.php.net/unsub.php

The pipe operator RFC has actually been mentioned before; the short takeway is: pipe operator works and has a benefit of using existing functions. The downside is that those are still functions, not methods, meaning you’ll still be left with [your_type]_ prefixes for all function names, unlike extension methods, where you can have multiple methods with the same name (for different types).

Regarding the -> syntax, I agree it looks confusing at first. This is the way it looks in the aforementioned languages (all of which use dot as member access operator):

“42”.toInt() // kotlin
’42’.parseInt() // dart
“42”.ParseInt() // c#

3 years ago by Larry Garfield — view source — reply

unread

The pipe operator RFC has actually been mentioned before; the short
takeway is: pipe operator works and has a benefit of using existing
functions. The downside is that those are still functions, not methods,
meaning you’ll still be left with [your_type]_ prefixes for all
function names, unlike extension methods, where you can have multiple
methods with the same name (for different types).

This is incorrect, and has been since functions could be namespaced. Please stop repeating this, it is FUD.

Also, "existing functions" is also not quite accurate. PIpe worked with any callable; the Partial Function Application RFC was intended to make turning arbitrary functions into callables, which could then be easily piped, but you can also use arbitrary callables, including closures and objects that implement __invoke(). array_map in its current form wouldn't be pipeable anyway as it requires multiple arguments, but higher order functions that are pipe-friendly as trivial to write. (See previous message for a link to many.)

--Larry Garfield

3 years ago by Alex Wells — view source — reply

unread

The pipe operator RFC has actually been mentioned before; the short
takeway is: pipe operator works and has a benefit of using existing
functions. The downside is that those are still functions, not methods,
meaning you’ll still be left with [your_type]_ prefixes for all
function names, unlike extension methods, where you can have multiple
methods with the same name (for different types).

This is incorrect, and has been since functions could be namespaced. Please stop repeating this, it is FUD.

Also, "existing functions" is also not quite accurate. PIpe worked with any callable; the Partial Function Application RFC was intended to make turning arbitrary functions into callables, which could then be easily piped, but you can also use arbitrary callables, including closures and objects that implement __invoke(). array_map in its current form wouldn't be pipeable anyway as it requires multiple arguments, but higher order functions that are pipe-friendly as trivial to write. (See previous message for a link to many.)

--Larry Garfield

--

To unsubscribe, visit: https://www.php.net/unsub.php

Functions can be namespaced indeed. I’m referring to another thread where I brought an example with Collection::map and array::map. You can easily define those as functions in different namespaces, but when it comes time to use it, you’ll likely end up having to use the same function name in a single file. It’s then one of three options:

you don’t import your functions, leading to ugly long calls: \Illuminate\Collection\map(…, fn () ..), \Some\Vendor\Arrays\map(…, fn () ..)
you do import your functions, but end up aliasing: use function Illuminate\Collection\map as collection_map;, use function Some\Vendor\Arrays\map as array_map;
you define your functions with prefixes from the beginning, just to avoid having to manually alias them all the time: use function Illuminate\Collection\collection_map;

All of the solutions are far from perfect. I apologize if I’m missing something.

3 years ago by Rowan Tommins — view source — reply

unread

You could argue the problem is that all of these are single-liners, so here are the same examples, but multiline formatted:

When people talk about avoiding one-liners, they're not just talking
about whitespace, but other refactoring. For example, introducing
intermediate variables:

$fileNameComponents = explode('', $file->getName() );
$slicedComponents = array_slice($fileNameComponents, 4);
// (most likely there's a better variable name, which would explain
why we're ignoring those components)
$className = Str::studly( implode('', $slicedComponents) );

Or adding additional helper functions:

$fileNameComponents = explode('_', $file->getName() );
$slicedComponents = array_slice($fileNameComponents, 4);
$className = Str::studlyFromArray( $slicedComponents );

Or even, since "Str::studly" probably calls explode() internally anyway:

$className = Str::studlyWithSlice( $file->getName(), 4 );

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’t move it, it removes it. You’re technically not passing
that value as an argument anymore anywhere in your code, your value
becomes the implicit
expression you’re working with. That becomes even more obvious when
multiple method calls are chained and don’t need to pass it into every
function call.

I think what Paul means is that "$foo->bar($baz)" and "bar($foo, $baz)"
have the same "words" - the "$foo" is there in both cases, just in
different positions. The same is true of nesting vs chaining:
"$foo->bar()->baz()" has the same "words" as "baz( bar( $foo ) )", just
in a different order.

I do agree that the left-to-right order is nicer to read than the nested
version, but that's largely opinion - it's not actually any shorter.

Regards,

--
Rowan Tommins
[IMSoP]

3 years ago by Alex Wells — view source — reply

unread

You could argue the problem is that all of these are single-liners, so here are the same examples, but multiline formatted:

When people talk about avoiding one-liners, they're not just talking about whitespace, but other refactoring. For example, introducing intermediate variables:

$fileNameComponents = explode('', $file->getName() );
$slicedComponents = array_slice($fileNameComponents, 4);
// (most likely there's a better variable name, which would explain why we're ignoring those components)
$className = Str::studly( implode('', $slicedComponents) );

Or adding additional helper functions:

$fileNameComponents = explode('_', $file->getName() );
$slicedComponents = array_slice($fileNameComponents, 4);
$className = Str::studlyFromArray( $slicedComponents );

Or even, since "Str::studly" probably calls explode() internally anyway:

$className = Str::studlyWithSlice( $file->getName(), 4 );

I agree that this is a solution for many cases. However, the goal of the comparison was to show reduced cognitive complexity, which I don’t believe is what was achieved by splitting a simple expression into mulitple lines with multiple variables. It gets progressively harder to “scan through” if you’re just trying to get a global picture of what’s happening and not specifically understand why these lines exist and what they’re doing. Sometimes you just need a neat one-liner and that’s enough :)

Besides, variables are statements, making these a statement list, not an expression, meaning they can’t be used as one in an arrow function or a throw expression.

3 years ago by Larry Garfield — view source — reply

unread

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.)

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

3 years ago by Alex Wells — view source — reply

unread

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.)

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

--

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.

3 years ago by Larry Garfield — view source — reply

unread

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

--

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

3 years ago by Alex Wells — view source — reply

unread

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

--

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

--

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 :)