Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112089
User-Agent: Cyrus-JMAP/3.3.0-502-gfef6c88-fm-20201019.001-gfef6c888
Mime-Version: 1.0
Message-ID: <11124061-cfeb-4668-8a8d-a11aa683477a@www.fastmail.com>
In-Reply-To: <41AA7084-18F3-431B-B135-46C44FC26D1E@newclarity.net>
References: <eb143f8b-b242-47bb-9858-e6150dd7aea4@www.fastmail.com>
 <41AA7084-18F3-431B-B135-46C44FC26D1E@newclarity.net>
Date: Wed, 21 Oct 2020 07:50:12 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Short-function syntax
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Oct 20, 2020, at 11:08 PM, Mike Schinkel wrote:
> > On Oct 20, 2020, at 2:19 PM, Larry Garfield <larry@garfieldtech.com> wrote:
> > 
> > A while back, Nikita mentioned that it should now be easy to offer an abbreviated syntax for functions that are just a single expression.  I decided to take a crack at it and it turns out he was right.  I thus offer this RFC:
> > 
> > https://wiki.php.net/rfc/short-functions
> > 
> > Hopefully I made a decent enough case for it.  It's entirely a convenience factor, but I think for many OOP cases (getter methods and factored out operations) and functional cases (where functions should generally be a single expression conceptually) it does make the code nicer, more compact, and more readable.
> 
> Simple and elegant.  I like it.
> 
> I have two comments, but not about the feature.  
> 
> One comment is about the RFC itself, and the other is about a use-case 
> used to justify the feature that could warrant its own bespoke feature.
> 
> 
> 1. The section on "Conditional methods" is really just an argument 
> about the benefits of encapsulating complex logic into well-named 
> functions as you could achieve exactly the same benefit with the 
> existing function syntax.  It does not appear to me that it provides 
> any specific justification for the feature in the RFC. Should it really 
> be part of the RFC?

In pre-RFC discussion, one of the pushbacks I got was "pfft, how common are single-line methods anyway?"  That example is mainly to demonstrate "quite common, actually, in fact common refactoring patterns tend to produce them a lot."  It's not the refactoring itself that benefits, per se, as it is the refactoring technique produces functions that would benefit from it.

> 2. In the section "Decorating functions in live code" where you state 
> "Often times, methods exist that are just delegating to some other 
> method, either in the same object or a composed object." I think we 
> could see great benefit from explicitly building delegation into 
> classes much like how Go provides type embedding[1]. For PHP, extending 
> the syntax for traits could be used to support delegation of one class 
> to another embedded class. Can you see this as a potential feature?
> 
> -Mike

I'd be in favor of some kind of automated "delegate this interface's methods to this object property" syntax, although that is unrelated to the RFC at hand.

--Larry Garfield