> On 11 Aug 2022, at 17:25, Christian Schneider <cschn...@cschneid.com> wrote:
>
> Am 11.08.2022 um 11:03 schrieb Alex Wells <autau...@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#
```
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
