> On 11 Aug 2022, at 22:02, Larry Garfield 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
> On 11 Aug 2022, at 21:58, Larry Garfield wrote:
>
> On Thu, Aug 11, 2022, at 1:51 PM, Alex Wells wrote:
>
>> 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
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
> On 11 Aug 2022, at 21:42, Larry Garfield 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 tho
On Thu, Aug 11, 2022, at 1:51 PM, Alex Wells wrote:
> 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 lef
> On 11 Aug 2022, at 17:25, Christian Schneider wrote:
>
> Am 11.08.2022 um 11:03 schrieb Alex Wells :
>> 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
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 trivi
> On 11 Aug 2022, at 18:10, Rowan Tommins wrote:
>
> On 11/08/2022 10:03, Alex Wells wrote:
>> 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 ta
On 11/08/2022 10:03, Alex Wells wrote:
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, introd
Am 11.08.2022 um 11:03 schrieb Alex Wells :
> 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 c
> On 11 Aug 2022, at 07:36, Paul Crovella wrote:
>
> 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
> On 11 Aug 2022, at 00:30, Rowan Tommins wrote:
>
> 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 __cal
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
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. Sec
> 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
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
16 matches
Mail list logo
