Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118408 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 18198 invoked from network); 11 Aug 2022 02:34:45 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 11 Aug 2022 02:34:45 -0000 To: internals@lists.php.net Date: Wed, 10 Aug 2022 21:36:43 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.1.1 Content-Language: en-US References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 172.113.137.202 Subject: Re: [Concept] Extension methods From: paul.crovella@gmail.com (Paul Crovella) Message-ID: On 8/10/2022 7:17 AM, Alex Wells wrote: > 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.