Re: [RFC] Short-function syntax
| From: | Larry Garfield | Date: | Wed, 21 Oct 2020 12:50:12 +0000 |
| Subject: | Re: [RFC] Short-function syntax | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-112089@lists.php.net to get a copy of this message | ||
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