Re: [Concept] Extension methods

> On 11 Aug 2022, at 17:25, Christian Schneider <cschneid@cschneid.com> wrote: > > 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): >> ```php >> $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 > > -- > PHP Internals - PHP Runtime Development Mailing List > 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# ```